New resolver depends on req order in presence of direct URLs?

[sbidoul]

Environment

• pip version: master, today
• Python version: 3
• OS: Irrelevant, most probably

Description

The new resolver seems to get confused when a regular requirement and a direct URL requirement are both present in the requirement set.

This test case was inspired by the conversation in #8210.

How to Reproduce

Create two packages (pkg1 and pkg2) which both depend on a third one (packaging) one via a regular specifier, and the other via a direct URL.

Create pkg1/setup.py:

from setuptools import setup

setup(
    name="pkg1",
    install_requires=[
        "packaging@ git+https://github.com/pypa/packaging@20.1",
    ],
)

and pkg2/setup.py:

from setuptools import setup

setup(
    name="pkg2",
    install_requires=[
        "packaging",
    ],
)

Then in a fresh vritualenv, run:

$ env PIP_UNSTABLE_FEATURE=resolver pip install ./pkg1 ./pkg2
Processing ./pkg1
Processing ./pkg2
Collecting packaging@ git+https://github.com/pypa/packaging@20.1
  Cloning https://github.com/pypa/packaging (to revision 20.1) to /tmp/pip-install-9uhtuof1/packaging
  Running command git clone -q https://github.com/pypa/packaging /tmp/pip-install-9uhtuof1/packaging
  Running command git checkout -q 71b46f5a4ad9275b67c4b4eae873930f2d604aa9
Collecting six
  Using cached six-1.14.0.tar.gz (33 kB)
Collecting pyparsing>=2.0.2
  Using cached pyparsing-2.4.7.tar.gz (649 kB)
Building wheels for collected packages: pkg1, pkg2, packaging, six, pyparsing
  Building wheel for pkg1 (setup.py) ... done
  Created wheel for pkg1: filename=pkg1-0.0.0-py3-none-any.whl size=1011 sha256=c4ca6203a6c3c14eee24c66a3962375b17bbf71cb3b496054c94e185c43d28ac
  Stored in directory: /tmp/pip-ephem-wheel-cache-c5riwiux/wheels/37/f7/8c/d296b3430885ba049ecbf474935579f535c92b326cfe1c6a98
  Building wheel for pkg2 (setup.py) ... done
  Created wheel for pkg2: filename=pkg2-0.0.0-py3-none-any.whl size=982 sha256=52c2a56a0ceca0ae040a25b1312d8c1e06e3d8d324c61ada0dfc1fb69a2f0a9c
  Stored in directory: /tmp/pip-ephem-wheel-cache-c5riwiux/wheels/b9/1c/6e/2e41e65a991d3cabe419ff79a329568d52b6d6b184b7d5bbd0
  Building wheel for packaging (setup.py) ... done
  Created wheel for packaging: filename=packaging-20.1-py2.py3-none-any.whl size=36952 sha256=7dad729a94ea1dba65ed2ae8926afb35048a03cd006d6fe32f2380141185ae45
  Stored in directory: /tmp/pip-ephem-wheel-cache-c5riwiux/wheels/5b/0d/34/74f6ed24cd766f865f7013453911125d3728db1a0c0ada26ba
  Building wheel for six (setup.py) ... done
  Created wheel for six: filename=six-1.14.0-py2.py3-none-any.whl size=10938 sha256=e5fb72cf994d0acfba924dd902f6b158d9a6c19bbe36db461fb057178aefe3bc
  Stored in directory: /home/sbi-local/.cache/pip/wheels/0d/77/57/d754b06cb4b95868287f60b5a786db2416c0b5549b2d03c49c
  Building wheel for pyparsing (setup.py) ... done
  Created wheel for pyparsing: filename=pyparsing-2.4.7-py2.py3-none-any.whl size=67842 sha256=8d19de22994acea203be3b5d0dd0eb693b7029a19e6bfff4b81927d9492dbf4d
  Stored in directory: /home/sbi-local/.cache/pip/wheels/ad/8d/0f/ad334705ed78e380d5342429a624c46bd6ac4e2ba616d70eb6
Successfully built pkg1 pkg2 packaging six pyparsing
Installing collected packages: six, pyparsing, packaging, pkg2, pkg1
Successfully installed packaging-20.1 pkg1-0.0.0 pkg2-0.0.0 pyparsing-2.4.7 six-1.14.0

So far, so good.

Then in a fresh virtualenv, run:

$ env PIP_UNSTABLE_FEATURE=resolver pip install ./pkg2 ./pkg1
Processing ./pkg2
Processing ./pkg1
Collecting packaging@ git+https://github.com/pypa/packaging@20.1
  Cloning https://github.com/pypa/packaging (to revision 20.1) to /tmp/pip-install-f9rgku1a/packaging
  Running command git clone -q https://github.com/pypa/packaging /tmp/pip-install-f9rgku1a/packaging
  Running command git checkout -q 71b46f5a4ad9275b67c4b4eae873930f2d604aa9
ERROR: Could not find a version that satisfies the requirement packaging (from pkg2)
ERROR: Could not find a version that satisfies the requirement ExplicitRequirement(LinkCandidate('git+https://github.com/pypa/packaging@20.1')) (from pkg1)
ERROR: No matching distribution found for packaging, packaging

Expected behaviour

Both should give the same result.

[pfmoore]

There's a resolvelib update that we need to pick up that should fix this, but thanks for the reproducer.

If you're interested, the problem is that currently resolvelib gets the matches for the first requirement it sees, and then filters that list for each new requirement. It only asks new requirements for their matches if it backtracks (I think - maybe not even then). That's wrong, and thew new version asks later requirements for any additions to the list as well. (Details are more fiddly, but that's the general idea).

[uranusjr]

Yes, resolvelib had some naive assumptions (the provider should be able to get all possible versions of a package when it’s first initialised) that does not work in Python packaging. There has been some changes to the model so the provider can have a say in every dependency discovery round whether it knows more than previously, but I haven’t have the time to update the implementation in pip to use that. Thanks for noticing the problem!

I’ll also use this issue to track the related work (IIRC there was not an issue open here for this yet).

[sbidoul]

This works with the latest master. 👍

[uranusjr]

Yay! I’ll take the liberty and close this.