pip: `-e .` does not take precedence over pin in requirements file
I’ve been experimenting with using pip-compile for Jinja, and have run into an interesting circular dependency between Jinja and Sphinx. Jinja uses an editable install (-e .) for development. Jinja lists Sphinx in requirements.in for building docs. But Sphinx depends on Jinja, so jinja2==2.11.1 gets pinned in requirements.txt. But this pin overwrites the locally installed version of Jinja, which is what should be documented and tested.
I wanted to provide contributors with a command to set up a dev env. Using the current resolver, pip install -e . -r requirements.txt ends up installing jinja2==2.11.1 from requirements.txt instead of -e . The order of -e and -r in the command doesn’t matter.
Using the alpha resolver, pip install --unstable-feature=resolver -e . -r requirements.txt (or -r -e) produces an error.
$ pip install --unstable-feature=resolver -r requirements/dev.txt -e .
Obtaining file:///home/david/Projects/jinja
ERROR: Could not find a version that satisfies the requirement ExplicitRequirement(EditableCandidate('file:///home/david/Projects/jinja'))
ERROR: Could not find a version that satisfies the requirement jinja2==2.11.2
ERROR: No matching distribution found for jinja2, jinja2
I would expect a local install to always take precedence over pinned requirements. Otherwise, projects that depend on each other during development will have a more difficult time pinning requirements.
As a workaround, the editable install can be done as a separate command. Tox, Nox, and ReadTheDocs can install the local project after the dependencies, but adding a second command introduces a hard to detect way for new contributors to misconfigure their local environment.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 26 (14 by maintainers)
Commits related to this issue
- Add detail to docs on constraints changes with new resolver Related to #8307, #8115. — committed to brainwane/pip by brainwane 4 years ago
- Add detail to docs on constraints changes with new resolver Related to #8307, #8115. — committed to brainwane/pip by brainwane 4 years ago
- Add detail to docs on constraints changes with new resolver Related to #8307, #8115. — committed to brainwane/pip by brainwane 4 years ago
- Add detail to docs on constraints changes with new resolver Related to #8307, #8115. — committed to brainwane/pip by brainwane 4 years ago
- Add detail to docs on constraints changes with new resolver Related to #8307, #8115. — committed to brainwane/pip by brainwane 4 years ago
- Add detail to docs on constraints changes with new resolver Related to #8307, #8115. — committed to brainwane/pip by brainwane 4 years ago
- Add detail to docs on constraints changes with new resolver Related to #8307, #8115. — committed to brainwane/pip by brainwane 4 years ago
I’m fine with doing it in two steps, it’s good to hear that PyPA maintainers/contributors acknowledge it and don’t plan on breaking it. I was concerned because I hadn’t yet got that direct answer.
@pradyunsg unless you want to leave this open, I’m going to close it, I’m fine with your answer as the resolution to it.
For clarity, I’ve removed the new resolver label from this, and added the appropriate labels here.
This issue is requesting for a change in the behavior of pip’s handling of editables, when it conflicts with other requirements. The current resolver is giving an undesirable result, due to how it handles the conflicting requirements, and the new resolver is rejecting this as conflicting requirements have been fed into the resolver and its capable of detecting that.