pip._vendor.resolvelib.resolvers.ResolutionTooDeep: 200000 #12430
Comments
1kastner
added
S: needs triage
|
To be honest, I am a bit stuck on what I can do here. I would like to see where the conflict stems from - where in the dependency graph do we have the problem? |
|
PS: As this worked in the past, I have a locally working version of it, i.e.: As I have locall played around with a library or two, this might include some additional packages that are actually not needed for the project. |
|
👋🏽 Try running pip with |
|
Consolidating into #11480, since that's the tracking issue for improving this situation in general. This is a known gap of the tool; and the maximum verbosity logs contain the relevant information (it mentions when backtracking why a conflict/backtracking is happening). |
|
FYI I'm taking at a look at why this set of requirements causes Pip to reach ResolutionTooDeep I was able to reproduce using steps others will find a bit simpler, though took a couple of hours for me to run on my quite fast computer. Run I would strongly suggest OP add more lower bounds to their requirements. At a quick look at one of the backtracking steps Pip gets stuck on resolving The problem here is pip needs to choose a cause or a parent to backtrack on and there are a lot of choices and if the wrong choice is made Pip can spend a lot of time wasted trying to find the right resolution path. In this example I beleive if pip was intelligent about this step it could realize that I am working on an update to Pip's resolution that prefers backtracking on this conflicting causes: #12318 (comment). However, I had only considered when two specifiers conflict with each other, not when a parent version and specifier conflict. So I have started working on an update to the branch to handle this scenario and will provide feedback as soon as I have it implemented. I see in your case you've been able to come up with some constraints that solve your situation, but in general if you have some requirements that used to work but no longer do, one way to identify working constraints is to use |
|
Okay, I have updated my experimental Pip branch to prefer conflicting causes to handle this scenario: https://github.com/notatallshaw/pip/tree/prefer-conflicting-causes If you would like to assist in testing your use case you can install it like so: In my testing this now resolves very quickly. |
|
FYI, for OP you should be able to drastically speed up your resolution in the current version of Pip by including Also for others this simplified set of requirements also demonstrates this pathological behavior in Pip's current resolver: |
Test solution proposed at pypa/pip#12430 (comment)
|
@notatallshaw thank you for the extensive work! I have tried out your latest solution in https://github.com/1kastner/conflowgen/actions/runs/7159890013/job/19493640829?pr=201 and it worked like a charm. When is it planned to be published? |
Great! It's good to have more examples to push this forward.
Likely not for awhile, the are a number of steps that need to be done:
In particular I see step 4 as being a bit sticky as I still need to clean up the code, figure out some tests, write up a good explanation for Pip maintainers, formalize all the evidence I have that it is a general improvement, and convince it's worth spending the time to review and merge. It would be great if I did that by the next Pip release, but I could also see it taking a lot longer. In the mean time I suggest you follow my other workaround:
|
See pypa/pip#12430 (comment) for more information
|
Thank you for your guidance! The work-around is in place and l look forward to seeing this improvement to be merged. Best luck for the process! |
Description
A set of Python modules that could be installed jointly in the past runs now into
pip._vendor.resolvelib.resolvers.ResolutionTooDeep: 200000.Expected behavior
A quick installation of all required modules
pip version
23.3.1
Python version
3.8.18
OS
Ubuntu
How to Reproduce
Output
See https://github.com/1kastner/conflowgen/actions/runs/7158163375/job/19489894194?pr=201
Code of Conduct
The text was updated successfully, but these errors were encountered: