-
-
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
Breaking changes from 2023.7.23 to 2023.8.20 when using pyproject.toml #5846
Comments
@ddl-kfrench I cannot be certain yet, but it seems to be it may possibly also be fixed by #5845 -- if you have some bandwidth to check, that would be helpful. |
@matteius It doesn't fix the issue because the problem occurs after parsing the pyproject and leaving the |
@fraenkel The thing that I don't understand is, pipenv is not actually responsible for parsing the pyproject.toml -- we are feeding the top level requirements into the pip resolver and the resolver is what is introspecting those other things.
What does this mean exactly? There is an extra @ and there shouldn't be? Or that there isn't a @ and there should be ... or something else? I am wondering too if the version of 0.0.0 could be related to the issue at all? |
Actually this stands out as an issue:
The lock file has a ref which is the actual commit hash and the git has the ref as well -- I think this is not right. Did the new version of pipenv generate this lock file or was it from a prior version? It seems when I generate a new lock file using a similar command: The new lock file entry does not have the ref in the vcs part:
This is another case where we do not have tests showing this old style lock entry, and nobody reported it during the testing window for that branch. I guess my position right now is regenerating the lock file should fix it, but if someone wants to take on trying to peel that specifier off the vcs part of the URL if it exists(on the install pip lines that get generated) in order to make it more backwards compatible, I am open to it, but I lack time resources to tack it on right now. |
Even with your patch, I see the following
In my case, the generated Pipfile.lock still has the branch/tag on the git reference, like: |
@fraenkel I believe then its because the Pipfile also has the @v0.4.0 style ref in the vcs URL and that is getting transferred over to the lock-file. We can try to add a patch for this case, but that is what I think is happening. |
I just pushed another change to https://github.com/pypa/pipenv/pull/5845/files that may handle it being in the Pipfile (might still require a re-lock) -- probably a little early to report this since the test runner is just kicking off ... |
Ok that prior commit looked good for the Pipfile part, I just pushed another change to that branch which should make it so you wouldn't have to re-lock. |
Just cut release |
Issue description
We noticed CI jobs began to fail over the weekend when upstream
pipenv
was picked up to performpipenv install --dev --deploy
on a repository with no changes other than an upgrade frompipenv - 2023.7.23
topipenv - 2023.8.20
After some debugging, we found it appears to be due to a breaking change in how dependencies are resolved in
pyproject.toml
between these versions ofpipenv
. Based on the diff (v2023.7.23...v2023.8.20#diff-d5fa37485876aa13851c69343a10f66e9c5b8820257447a0a0b1645776d09172R42), there were a fair amount of modifications made in how requirements are parsed, including deprecation ofrequirementslib
.Expected result
pipenv install
should continue to work for dependencies whose versions are specified inpyproject.toml
rather than justPipfile
Actual result
redacted logs from successful step using
pipenv version 2023.7.23
redacted logs from failing step using
pipenv version 2023.8.20
the generated
Pipfile.lock
forcommon
when running2023.8.20
looks correctwe tested the latest (
8.20
)pipenv install
on a different repository wherepyproject.toml
does not include dependency versions and they are only contained inPipfile
. in this scenario,pipenv install
succeeds.however, in the newly failing job where
pyproject.toml
does include versions,pipenv install --deploy
fails.example of pyproject.toml
the same
pyproject.toml
succeeds in2023.7.23
and fails in2023.8.20
Steps to replicate
for a repository with a
pyproject.toml
file that has agit+ssh
dependency, runpipenv install --deploy
.can't include
pipenv --support
-- relevant redacted outputs included aboveThe text was updated successfully, but these errors were encountered: