Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misleading ResolutionImpossible message w/ a requirement duplicate and an incompatible Python runtime #11321

Open
1 task done
webknjaz opened this issue Jul 28, 2022 · 3 comments
Labels
C: dependency resolution About choosing which dependencies to install S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior

Comments

@webknjaz
Copy link
Member

Description

I've faced this by updating a pip-tools-managed constraints file under Python 3.9 but using these pins under Python 3.6. Obviously, some of them were incompatible (which I didn't notice immediately) but the problem I'm reporting is how pip communicates what's happened.

Pip errors out, claiming that two user requests of the same package are conflicting, when they are not. One of the requests has an unspecified requested version so basically anything matches, and the other one is pinned to a specific release. So basically out of these two, the resolver would select the pinned one, and it'd be compatible with a more broad request.

Keeping the above in mind, what pip suggests in the error message is not really true/obvious. I suppose that because the pin has incompatible python_version, it's facing an actual (invisible to the user) conflict. But this information isn't mentioned in the log which leads to a misleading impression.

I've crafted a reproducer below.

Expected behavior

The error message should specify that it's Require-Python that causes the problem, not two user requests that are actually compatible with each other.

pip version

Unknown but I reproduced this locally with v22.2.1 and v21.3.1

Python version

3.6 on CI, reproduced locally with 3.8

OS

macos-latest @ GHA, Gentoo Linux locally

How to Reproduce

$ python3.7 -m pip install django django==4.0.6
Collecting django
  Using cached Django-3.2.14-py3-none-any.whl (7.9 MB)
ERROR: Cannot install django and django==4.0.6 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested django
    The user requested django==4.0.6

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

(in my case, this was caused by setuptools with older pip and older Python version but I've found another package to demonstrate it under a supported Python version)

Output

ERROR: Cannot install setuptools because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested setuptools
    The user requested (constraint) setuptools==63.2.0

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies

Code of Conduct

@webknjaz webknjaz added type: bug A confirmed bug or unintended behavior S: needs triage Issues/PRs that need to be triaged labels Jul 28, 2022
webknjaz added a commit to webknjaz/pylibssh that referenced this issue Jul 28, 2022
@webknjaz
Copy link
Member Author

This is potentially similar to #9811 and #10953. I haven't attempted to debug this, though. Just made an educated guess based on the behavior.

webknjaz added a commit to webknjaz/pylibssh that referenced this issue Jul 28, 2022
@uranusjr
Copy link
Member

#10421 maye help with this.

@uranusjr uranusjr added the C: dependency resolution About choosing which dependencies to install label Jul 29, 2022
@webknjaz
Copy link
Member Author

Oh, I didn't realize @pradyunsg is still doing that effort.

webknjaz added a commit to ansible/pylibssh that referenced this issue Jul 29, 2022
…o devel

This patch attempts to integrate a forgotten constraints file into the
tox setup. The idea is to make PEP 517 builds reproducible. The
python-build tool (PEP 517 front-end) parses the build requirements
from `pyproject.toml` and `pip install`s them into an ephemeral
temporary virtualenv. Unfortunately, this tool does not expose any
interface to pin those requirements. But the underlying tool, pip,
supports setting CLI options through env vars. So the `--constraint`
option corresponds to `PIP_CONSTRAINT` env var which this change
relies on.

The constraints file can be regenerated as follows:

    $ python -c 'from pathlib import Path; from sys import argv; from tomli import loads; print("\n".join(loads(Path(argv[1]).read_text())["build-system"].get("requires", [])))' pyproject.toml | python3 -m piptools compile --allow-unsafe --generate-hashes --strip-extras --output-file requirements-build.txt -

This change temporarily disables including hashes into the constraints
file per pypa/pip#9243.
It also sticks to generating the pins under the lowest-supported Python
version which is Python 3.6 to address
pypa/pip#11321.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: dependency resolution About choosing which dependencies to install S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

2 participants