Issue using `pipenv upgrade`

[rwlogel]

Issue description

When running pipenv upgrade django==4.2.18 it only updates the default package and ignores the duplicate reference in the develop package.

In our Pipfile we currently have django==4.2.16 pinned. In our dev-packages we have packages that depend on django but the version is not explicitly specified. If we modify the Pipfile to be 4.2.18 and run pipenv lock it will correctly update the reference to django in the default and dev-packages sections, but it also pulls in the latest changes for all implicit dependencies.

Running pipenv upgrade django==4.2.18 upgrades django without pulling in any unrelated changes which is exactly what we are after, but it fails to update dev-packages.

Expected result

I would expect that since the lock command keeps the common dependencies between default and dev-packages in sync that the upgrade command would do the same.

Actual result

Here is the resulting diff when running pipenv upgrade django==4.2.18:

diff --git a/src/Pipfile b/src/Pipfile
index 4413201..82a6407 100644
--- a/src/Pipfile
+++ b/src/Pipfile
@@ -10,7 +10,6 @@ boto3 = "==1.28.8"
 celery = "==5.2.2"
 cryptography = "==38.0.3"
 database-sanitizer = "==1.1.0"
-django = "==4.2.16"
 django-autocompletefilter = "==0.0.8"
 django-bleach = "==3.1.0"
 django-bulk-update = "==2.2.0"
@@ -59,6 +58,7 @@ redis = "==3.5.3"
 scipy = "1.11.4"
 pysaml2 = "==7.5.0"
 clean = "*"
+django = "==4.2.18"
 
 [dev-packages]
 autopep8 = ">=1.5.4"
diff --git a/src/Pipfile.lock b/src/Pipfile.lock
index b66bc05..4d42b63 100644
--- a/src/Pipfile.lock
+++ b/src/Pipfile.lock
@@ -1,7 +1,7 @@
 {
     "_meta": {
         "hash": {
-            "sha256": "0408a945954a93bbfd41554bdee7e85efdb8b9ed3d0ee96654ad9b85a59b6828"
+            "sha256": "d5800b1a9e91b302ccc2b1446f9bd6bd87473449671c68ece5ca066b2deb54a7"
         },
         "pipfile-spec": 6,
         "requires": {
@@ -484,12 +484,12 @@
         },
         "django": {
             "hashes": [
-                "sha256:1ddc333a16fc139fd253035a1606bb24261951bbc3a6ca256717fa06cc41a898",
-                "sha256:6f1616c2786c408ce86ab7e10f792b8f15742f7b7b7460243929cb371e7f1dad"
+                "sha256:52ae8eacf635617c0f13b44f749e5ea13dc34262819b2cc8c8636abb08d82c4b",
+                "sha256:ba52eff7e228f1c775d5b0db2ba53d8c49d2f8bfe6ca0234df6b7dd12fb25b19"
             ],
             "index": "pypi",
             "markers": "python_version >= '3.8'",
-            "version": "==4.2.16"
+            "version": "==4.2.18"
         },
         "django-admin-rangefilter": {
             "hashes": [
@@ -1631,11 +1631,11 @@
         },
         "sqlparse": {
             "hashes": [
-                "sha256:773dcbf9a5ab44a090f3441e2180efe2560220203dc2f8c0b0fa141e18b505e4",
-                "sha256:bb6b4df465655ef332548e24f08e205afc81b9ab86cb1c45657a7ff173a3a00e"
+                "sha256:09f67787f56a0b16ecdbde1bfc7f5d9c3371ca683cfeaa8e6ff60b4807ec9272",
+                "sha256:cf2196ed3418f3ba5de6af7e82c694a9fbdbfecccdfc72e281548517081f16ca"
             ],
             "markers": "python_version >= '3.8'",
-            "version": "==0.5.1"
+            "version": "==0.5.3"
         },
         "standardjson": {
             "hashes": [

The django packages on line Pipfile.lock:2469 is still version 4.2.16. When we didn't notice this and did the following:

pipenv install         # Install default packages first
pipenv install --dev   # Install addition dev-packages

We end up with the downgraded version.

Steps to replicate

Use attached files and just run pipenv upgrade django==4.2.18.

Pipfile.txt

Pipfile.lock.txt

---

$ pipenv --support

Pipenv version: '2024.4.1'

Pipenv location: '/usr/local/lib/python3.11/site-packages/pipenv'

Python location: '/usr/local/bin/python3.11'

OS Name: 'posix'

User pip version: '24.3.1'

user Python installations found:

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.11.10',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '5.15.0-131-generic',
 'platform_system': 'Linux',
 'platform_version': '#141-Ubuntu SMP Fri Jan 10 21:18:28 UTC 2025',
 'python_full_version': '3.11.10',
 'python_version': '3.11',
 'sys_platform': 'linux'}

System environment variables:

• PYTHON_SHA256
• HOSTNAME
• PYTHON_VERSION
• PWD
• HOME
• LANG
• GPG_KEY
• TERM
• SHLVL
• PATH
• _
• OLDPWD
• PIP_DISABLE_PIP_VERSION_CHECK
• PYTHONDONTWRITEBYTECODE
• PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:

Debug–specific environment variables:

• PATH: /usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
• LANG: C.UTF-8
• PWD: /src

---

Contents of Pipfile ('/src/Pipfile'):

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
argon2-cffi = "==21.1.0"
awscli = "==1.29.8"
boto3 = "==1.28.8"
celery = "==5.2.2"
cryptography = "==38.0.3"
database-sanitizer = "==1.1.0"
django = "==4.2.16"
django-autocompletefilter = "==0.0.8"
django-bleach = "==3.1.0"
django-bulk-update = "==2.2.0"
django-cors-headers = "==4.2.0"
django-admin-rangefilter = "==0.12.1"
django-environ = "==0.11.2"
django-extensions = "==3.2.3"
django-filter = "==23.2"
django-health-check = "==3.17.0"
django-oauth-toolkit = "==1.7.1"
django-otp = "==1.2.4"
django-parler = "==2.3"
django-parler-rest = "==2.2"
django-prettyjson = "==0.4.1"
django-redis = "==5.4.0"
django-allauth = "==0.54.0"
django-ses = "==3.5.0"
django-silk = "==5.0.4"
django-simple-history = "==3.4.0"
djangorestframework = "==3.15.2"
djangorestframework-gis = "==1.0.0"
djangorestframework-simplejwt = {extras = ["crypto"], version = "==5.3.0"}
django-rest-multiple-models = "==2.1.3"
dj-rest-auth = {extras = ["with_social"], version = "==4.0.1"}
drf-nested-routers = "==0.93.4"
drf-yasg = "==1.21.7"
googlemaps = "==4.5.3"
gunicorn = "==22.0.0"
jsonschema = {version = "==4.2.1", extras = ["format"]}
kombu = "==5.2.2"
lxml = "==5.2.2"
model-bakery = "==1.18.2"
names = "==0.3.0"
openai = "==1.37.1"
psutil = "==5.8.0"
psycopg = "==3.1.12"
pyOpenSSL = "==22.1.0"
pycryptodome = "==3.19.1"
pycodestyle = "==2.11.1"
pysftp = "==0.2.9"
python-baseconv = "==1.2.2"
python-gnupg = "==0.4.8"
python3-saml = "==1.16.0"
qrcode = "==7.3.1"
redis = "==3.5.3"
scipy = "1.11.4"
pysaml2 = "==7.5.0"
clean = "*"

[dev-packages]
autopep8 = ">=1.5.4"
coverage = ">=5.5"
django-debug-toolbar = "==3.2.2"
django-fixture-magic = ">=0.1.5"
flake8 = "==6.1.0"
flake8-bugbear = ">=21.9.2"
flake8-commas = ">=2.0.0"
flake8-import-order = ">=0.18.1"
freezegun = ">=1.1.0"
ipykernel = ">=5.1.3"
ipython = ">=7.26.0"
ipywidgets = ">=7.5.1"
locust = "==2.5.1"
matplotlib = ">=v3.4.3"
moto = {extras = ["s3"], version = "4.0.10"}
pandas = "*"
pep8-naming = ">=0.12.1"
requests = "*"
rope = ">=0.19.0"
tblib = ">=1.5.0"
unittest-xml-reporting = ">=3.0.2"
notebook = "*"

[requires]
python_version = "3.11"

Contents of Pipfile.lock ('/src/Pipfile.lock'): (See attachment)

[matteius]

@rwlogel Could you check if #6361 positively impacts/fixes what you are reporting?

[rwlogel]

@matteius Ticket #6361 did correct the version in both places which was good. But it also introduced an explicit dependency in the dev-packages that probably shouldn't be there, see attached.

issue-6361-result.txt

[rwlogel]

For reference this was an example repo I set up for GitHub when I first submitted this issue to them as a Dependabot issue.

https://github.com/rwlogel/pipenv-dependabot-example

[matteius]

Thanks for the feedback @rwlogel -- I just pushed up another commit to try and resolve that, but maybe see how the CI does with it before checking again.

[rwlogel]

@matteius I just tried this commit 67e187f and everything worked great. There was no change to the [dev-packages] in the Pipfile, but the reference were updated in both places in the Pipfile.lock.

One request would it be possible, when using upgrade if the package is already specified in the Pipfile could it update that line instead of pushing it to the bottom of the group?

[matteius]

The file management of the Pipfile and lockfile is actually problematic for a host of reasons; I had to eliminate caching of it for example to solve some other issues and read from disk. I think your best bet is to add the [pipenv] directive with the sort_pipfile set to true and then it will at least be sorted.