Skip to content

Idea - New Resolver/Install Option - One at a Time #12160

@notatallshaw

Description

@notatallshaw

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:

  1. Collect top level user requirements
  2. 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
  3. 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
  4. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions