-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Resolution is halted by sdists whose metadata extraction fail. #12212
Comments
For historical context, the underlying build issue is well known by the PyYAML team and documented here: yaml/pyyaml#601. This is of course a more general issue, but this was the exemplar case that brought the problem to my attention. |
I believe this was an intentional change when the build process fails, more details here: #10722 |
Aha! Ok - thank you, I did not think to poke around features (vs flags). I now know about |
Hrm, that was removed in 22.2 here: 8bebea8 I think the removal of the opt out is really unfortunate. In this case the issue is unresolvable without reverting to an older Pip because the problematic dependency is a (transitive) PEP-518 unbounded I'm guessing this was driven by desire for a simpler code base and maybe not anticipating issues like this (or else a calculation that these sorts of issues were rare enough / or people should upgrade their deps to work past broken releases downstream). |
@notatallshaw thanks again for cluing me in to the context. I'm pretty sure this is all working as intended and the opt-out is unlikely to be revived. I'll close this out. |
The change of default behaviour was motivated by user feedback, since backtracking on build failure, while reasonable in theory, causes too much user confusion in practice. The Note that although using |
Thanks @uranusjr. This all comes from a hermetic build context where setting up (mutating) a venv just so ahead of the main resolve event is not an option. |
Description
During a resolve (I encountered using
pip download
), newer versions of Pip halt instead of backtracking when a candidate sdist metadata extraction process fails. Older versions logged these errors and backtracked.Expected behavior
It seems that treating an sdist whose metadata fails to be extractable as a rejected candidate is more sensible than halting the resolve all together. This allows a project to make a faulty release, but still be resolvable by Pip in many circumstances (consumers have requirements satisfiable by earlier, non-broken releases).
pip version
Python version
3.11
OS
WSL Linux (Ubuntu 22.04)
How to Reproduce
Successful backtracks in the face of sdist metadata extraction using Pip 20.3.4:
Likewise success up through 21.3.1:
But failure starting at Pip 22.0:
And that style of fail-fast error persists to present day released Pip:
Output
N/A - commands and output are above.
Code of Conduct
The text was updated successfully, but these errors were encountered: