This could improve the case of upstream dependencies that mess up the…

[matteius]

This adds error handling around badly formed python specifiers which pip happily installs the packages for, and the resolver spits out whatever is in the setup.py, however it will be wrongly parsed when quoted. My proposal here is that we simply alert the user and proceed to finish their package locking, since the python specifier is hardly the most important part of the Pipfile.lock. Even the current specifiers are non deterministic in Pip 21.x which we have other issue reports about and seems to be resolved in Pip 22.x.

The issue

https://github.com/pypa/pipenv/issues/4681

The fix

Try/except and Alert/continue

The checklist

• [X] Associated issue
• [ ] A news fragment in the news/ directory to describe this fix with the extension .bugfix, .feature, .behavior, .doc. .vendor. or .trivial (this will appear in the release changelog). Use semantic line breaks and name the file after the issue number or the PR #.

[matteius]

@frostming If you think this is the right approach as I am beginning to think, then I can add a news fragment and a test that shows locking succeeds when the python specifier is broken. Easiest thing to do would be use exotic==1.10.0 as the test case, but the problem there is it would take a while for just that one test to run and the suite already takes too long.

[matteius]

Deferring this until the split-utils branch gets merged, and I'll rebase this change off where this util got moved to.

[matteius]

Replacement PR: https://github.com/pypa/pipenv/pull/5329