Open carlkibler opened 2 months ago
On my machine the resolution succeeds in 30s, with pydantic==1.10.7
pinned.
1min for me (pdm lock -v 60.83s user 0.55s system 75% cpu 1:21.24 total), on Linux. Pydantic 1.10.17 too. Seems like pip stops backtracking earlier.
@carlkibler you make good points though!
Make user aware of the 10k loop default limit.
Yep, could be printed in on each round like pdm.termui: ======== Starting round 61/10000 ========
.
What is a "normal" amount of loops for a project? 10, 50? 100? I would suggest after 1 minute or 100 resolution attempts, print a message telling the user the resolver will continue trying up to 10k times and how to configure that limit.
In addition to "round 61/10000", PDM could indeed issue a message in non-verbose mode every couple hundreds rounds.
I wonder if the default limit should be much lower (50? 100?) and tell users instead "in large projects the value may need to be set higher, and here's how...".
Note that it was initially set to 500, and this was generally way too low, so @frostming increased it by a lot. You'll probably find more info by grepping the git logs or PRs on GitHub.
You all are right, which is frustrating! Thanks for trying. Some fun updates for completeness: The gretel-python-client project did a release yesterday 30 minutes after this bug report, changing pydantic's pinned version from 1.10.13 to 1.10.17. I thought maybe that is why you all got different results. Alas, no.
Today:
~/.config/pip/pip.conf
. But behavior is same with or without it. Just including for completeness.So I can't replicate yesterday's behavior, which was up in the thousands of resolver attempts. Baffling stuff. I withdraw my specific bug report, until I actually replicate it.
-- I appreciate @pawamoy thinking over the UX suggestions and giving some feedback from history. Printing a message in non-verbose mode every few hundred rounds would be useful I think. So that's my final suggestion.
I am happy to re-craft this into a feature request toward that end, or close this and make a separate feature request. My only goal is to help you all not get pestered by issues like this one.
I thought maybe that is why you all got different results. Alas, no
No, I even used --exclude-newer=2024-07-15
to return to the old days but it also succeeds. There is no essential difference between 1.10.13 and 1.10.17, too.
Printing a message in non-verbose mode every few hundred rounds would be useful I think. So that's my final suggestion.
This sounds good to me.
Seems lots of work needed to
Printing a message in non-verbose mode every few hundred rounds
since the iteration is located in resolvelib.
I read other "infinite loop" bugs (#2633, #2545, #1119, #908) but wanted to point out the general bug of running the resolver through 10k tries when there's a fairly obvious unresolvable conflict.
Make sure you run commands with
-v
flag before pasting the output.Steps to reproduce
langchain
andgretel-python-client
. (file below)pyproject.toml:
Actual behavior
PDM will go into resolution spin up to value of
strategy.resolve_max_rounds
(default is 10k). Ok. Here's the conflict:pydantic==1.10.17
pydantic<3.0.0,>=2.7.4
pip reports the conflict immediately:
This is great because it's clear and tells me quickly. Having
pdm lock
work for 10+ minutes and not notice this is a bug to me.Expected behavior
I wonder if the default limit should be much lower (50? 100?) and tell users instead "in large projects the value may need to be set higher, and here's how...".
If a reasonable resolver attempts is <50, then make that the default to save time for the vast majority of uses, and tell huge-project users to set that value because they are a special case. It would be more user friendly.
Environment Information