Skip to content

Issue using pipenv upgrade #6350

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rwlogel opened this issue Mar 5, 2025 · 6 comments · Fixed by #6361
Closed

Issue using pipenv upgrade #6350

rwlogel opened this issue Mar 5, 2025 · 6 comments · Fixed by #6361
Labels
PR: awaiting-review The PR related to this issue is awaiting review by a maintainer. Type: Bug 🐛 This issue is a bug.

Comments

@rwlogel
Copy link

rwlogel commented Mar 5, 2025

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
Copy link
Member

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

@matteius matteius added Type: Bug 🐛 This issue is a bug. PR: awaiting-review The PR related to this issue is awaiting review by a maintainer. labels Mar 20, 2025
@rwlogel
Copy link
Author

rwlogel commented Mar 21, 2025

@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
Copy link
Author

rwlogel commented Mar 21, 2025

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
Copy link
Member

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
Copy link
Author

rwlogel commented Mar 21, 2025

@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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: awaiting-review The PR related to this issue is awaiting review by a maintainer. Type: Bug 🐛 This issue is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants