Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/pypa/pip/issues/8115 below:

Clarify and define install/upgrade behaviour for the new resolver · Issue #8115 · pypa/pip · GitHub

What's the problem this feature will solve?
Currently, pip doesn't really define what it will install, beyond this section in the docs. And the documentation for --upgrade says basically the same. Nowhere is the fact that "we prefer to leave the installed version alone unless --upgrade is specified" documented, that I could find.

Describe the solution you'd like
Clearly document pip's behaviour when deciding what to install, and implement that behaviour for the new resolver. Note that I specifically do not propose trying to either make the old resolver foillow the new definition, or make the definition match every quirk of the old resolver (although obviously in broad terms, the behaviour will be the same). The old resolver's behaviour grew over time, and is heavily influenced by what was feasible given the way it was implemented (that's a polite way of saying "it's broken" 🙂). We should focus on getting well-specified and understandable behaviour in the new resolver.

Proposed Behaviour
I propose the following rules for what to install based on a given set of requirements:

1. Normal behaviour for pip is to look for solutions to the resolution problem defined by the set of requirements given on the command line. That means that all packages named in the command line, plus packages named in their dependencies, recursively, will be considered.
2. We explicitly note that installed packages that are not part of the set identified above are not considered. This is debatable - it is possible to add an extra set of requirements that any installed packages must remain unchanged, and their dependencies must also be considered. See below in "Alternative Solutions".
3. When identifying solutions, pip will normally prioritise the installed version of a given package over any other. However, note that this does not mean that pip will certainly retain that version - other constraints may influence this. Also, "prioritise" is a slightly subtle term here - it is about influencing the order the resolver searches for solutions, not about "scoring" possible solutions and choosing the "best". I'd prefer to just use the somewhat-vague term "prioritise" here to avoid getting into technical details that users won't care about.
4. The --upgrade flag changes pip's behaviour to not prioritise installed versions for packages named on the command line. By default installed versions are still prioritised for packages which are only identified as dependencies. That's the "only-if-needed" upgrade strategy. The "eager" upgrade strategy extends this to all packages in the dependency tree (the installed version is never prioritised).
5. Apart from the special case handling of installed versions, newer versions will be preferred over older versions.

Alternative Solutions
One key alternative here is that we might want to also include dependency information for packages that are installed but are not part of the dependency graph otherwise. This is the question noted in (2) above. The benefit of this is that pip would avoid installing a set of packages that conflicts with something that is already installed. The downside is that the behaviour is more complex (both to implement and to describe) and may have odd corner cases.

I'm mildly inclined to prefer not adding that complexity, because I suspect the benefits will be marginal, but I can easily be persuaded otherwise. See #7744 for extra context.

Additional context
There's further information that we don't even have access to when looking at the bare fact that "A 1.0 is installed" alongside the fact that A 2.0 is now available. Did the user do pip install A and A 2.0 got released since? Did the user install some package that depended on A<2.0, which they have now uninstalled? Did the user explicitly do pip install A==1.0? This sort of links into the suggestion made elsewhere about using/extending REQUESTED, but I think it goes beyond that. Ultimately, it's about managing an environment definition and that's not pip's role - it's what pipenv and poetry do, and we don't want to get into that area.

martin12333 and bramgrooten

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4