-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Incorrect dependency version installed when specifying a git commit. #5973
Comments
See same issue (ref is null using git source w/commit hash) on MacOS w/python 3.11. Going back to 2023.7.23 resolves issue. |
I tried reproducing this without luck on Windows and ubuntu without luck, here is the output from Windows:
|
Also just verified this example worked on mac os using latest pipenv -- I am at a loss as to what you are saying. |
Could this caused by different python versions? Diff between your Pipfile and mine:
Diff between your Pipfile.lock and mine:
|
The windows test was actually using:
I used a variety of pythons across the three OS tests I ran and could not reproduce it. Doesn't mean its not an issue for you, but I am not sure yet what could be causing it. |
I ran the same test as @matteius on a fresh install, and got the same results. So I scratched my head a moment. I realized this wasn't equivalent to what I was doing. I find that when you add to an existing Pipfile, you run into the problem here. Simply doing an empty
Now you will find that the |
It is likely worth re-labelling this as a regression (in addition to a legitimate bug), unless it is unable to be reproduced. |
I can replicate this issue on Pipenv 2023.12.1. Machine: x86 i7, Ubuntu 22.04.4 64bit Pipfile.lock example:
PipLock example:
Rolling back to |
I'm experiencing this with 2024.1.0 |
@ohshazbot could you check if you experience it on this branch: #6276 |
Sorry matteius, I think I got to a resolution before I saw your reply. But in my case, I'm not sure if it's unsupported behavior, as I was trying to install a specific commit whereas all the documentation only seems to support installing a git branch. And lookikng at the log difference between specifying branch and sha, the sha approach just pulls the latest commit from the default branch. So once I flipped my request over to using a branch identifier instead it worked as intended. So-
I will say that this was also causing other random failures that manifested as
, which were pretty useless until I realized there was a verbose flag that brought my attention to errors like
This was a package I recently migrated from a requirements.txt file and worked fine with the shas. |
Thank you so much for this analysis @ohshazbot -- it is exactly as you describe and the cause of why I opened #6266 Your findings will help me narrow this regression down further in the future. |
Coolio, this is a company setup to sanitizing is a bit of a pain, but if there's any other details I can share LMK |
Issue description
When I try to install a specific git commit of a repository, pipenv ignores the commit hash and installs the head.
Expected result
I expect to see the specified commit hash replicated in
Pipfile.lock
and the specified commit of the package installed in the virtual environment.Actual result
The
Pipfile.lock
contains"ref": null
in the package entry and the head of the package repository is installed in the virtual environment.Steps to replicate
Inspect the myhdl entry in
Pipfile.lock
. On my system theref
is set tonull
.To confirm, perform an additional check:
Which confirms that the installed myhdl is the head.
My debugging efforts
Release 2023.7.23 works as expected.
Releases 2023.8.19 and 2023.8.20 fail with an error.
Subsequent releases look to complete successfully but install the wrong version and set
null
in the lock file.The problematic code looks to be on lines 115 to 118 of
pipenv/pipenv/utils/locking.py
The text was updated successfully, but these errors were encountered: