You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the Pip new resolver was added a hack to delay backtracking on setuptools was introduced in PR #9249, this was from the observation #9187 (comment) as part of the reason for causing long times backtracking in #9203.
However since then the ecosystem has drastically improved and it is very difficult to reproduce this use case without pypi-timemachine.
If you do use "pypi-timemachine" to reproduce this you will find that the hack is no longer required on pip main, probably thanks to recent improvements in resolvelib.
Expected behavior
Shouldn't need specific hacks for packages, if backtracking is powerful enough individual hacks are likely to cause more problems than they solve.
pip version
main
Python version
3.7+
OS
any
How to Reproduce
Install pypy-timemachine
Run like so: pypi-timemachine 2020-12-02 --port 9999
Create constraints.txt with the contents argparse>=1
Run pip like so python3.7 -m pip download apache-airflow[all]==1.10.13 -c constraints.txt -d downloads --index-url http://localhost:9999
Output
To come up with an objective assessment of if changes to the resolver had a positive or negative impact we will take the total number of packages Pip had to download as part of backtracking and subtract the number of packages that were saved to the download folder as part of the download command. This number is the "extra nodes" that Pip had to include in the backtracking graph, and is likely represents an exponential increase in time spent backtracking.
There was therefore no difference between having the setuptools hack or not.
I tested on Pip 23.0.1 I couldn't get resolution to finish (though the setuptools hack changed backtracking path quite significantly), I also tested using resolvelib main (e383b40) and saw no difference between that and Pip main in this test case.
Description
When the Pip new resolver was added a hack to delay backtracking on setuptools was introduced in PR #9249, this was from the observation #9187 (comment) as part of the reason for causing long times backtracking in #9203.
However since then the ecosystem has drastically improved and it is very difficult to reproduce this use case without pypi-timemachine.
If you do use "pypi-timemachine" to reproduce this you will find that the hack is no longer required on pip main, probably thanks to recent improvements in resolvelib.
Expected behavior
Shouldn't need specific hacks for packages, if backtracking is powerful enough individual hacks are likely to cause more problems than they solve.
pip version
main
Python version
3.7+
OS
any
How to Reproduce
pypy-timemachine
pypi-timemachine 2020-12-02 --port 9999
constraints.txt
with the contentsargparse>=1
python3.7 -m pip download apache-airflow[all]==1.10.13 -c constraints.txt -d downloads --index-url http://localhost:9999
Output
To come up with an objective assessment of if changes to the resolver had a positive or negative impact we will take the total number of packages Pip had to download as part of backtracking and subtract the number of packages that were saved to the download folder as part of the download command. This number is the "extra nodes" that Pip had to include in the backtracking graph, and is likely represents an exponential increase in time spent backtracking.
There was therefore no difference between having the setuptools hack or not.
I tested on Pip 23.0.1 I couldn't get resolution to finish (though the setuptools hack changed backtracking path quite significantly), I also tested using resolvelib main (e383b40) and saw no difference between that and Pip main in this test case.
Code of Conduct
The text was updated successfully, but these errors were encountered: