-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
What's the problem this feature will solve?
The legacy resolver is coming on being deprecated for three years now, however it seems like there is still significant trepidation in removing it from Pip, the idea would be to offer a new resolver/install option that covered any use cases left but relied on the new resolver code.
Describe the solution you'd like
The resolver/installer option would do the following:
- Collect top level user requirements
- Take the first user requirement and install it as though it was the only requirement specified, using the top level user requirements as a set of constraints
- Take the second user requirement and install it as though it was the only requirement specified, using the top level user requirements as a set of constraints, and as though this and the previous step were two separate install commands
- Continue like this until all user requirements have been completed
This would allow conflicting packages to be installed from transitive dependencies, but still force the top level user requirements to be consistent and not broken.
This feature would be documented as:
- not recommended
- can install inconsistent environments
- can fail part way though leaving some packages installed but others not installed
Alternative Solutions
- Keep legacy resolver forever
- Remove legacy resolver with no alternative, break some users workflows
Additional context
IMO most users who still have the legacy resolver option enabled probably don't need it and just have it left over for when the current resolver was turned on by default and caused lots of problems.
But I do know two projects that are reliant on the legacy resolver (at least last I checked):
In both cases my understanding is the scale of requirements they have makes it impossible to come to a clean resolution on all packages and ultimately they need to install packages which list themselves as having incompatible requirements (even if in practice there is a functionally working solution). There may be other reasons as well.
Code of Conduct
- I agree to follow the PSF Code of Conduct.