This always prepares each explicit requirements when the resolver is
run, instead of when they are being resolved. But we always want to
prepare them anyway (an explicit requirement has only one candidate, so
it's either do or die), so this is not really a problem.
The resolver collects previously known incompatibilites and sends them
to the provider. But previously the provider does not correctly exclude
the currently-installed candidate if it is present in that
incompatibility list, causing the resolver to enter a loop trying that
same candidate. This patch correctly applies incompat_ids when producing
an AlreadyInstalledCandidate and exclude it if its id() is in the set.
When a requirement is requested multiple times, some via a direct URL
("req @ URL") and some not but with extras ("req[extra] VERSION"), the
resolver previous could not correctly find "req[extra]" if "req" is
available in an index.
This additional logic makes the resolver, when encountering a
requirement with identifier "req[extra]", to also look for explicit
candidates listed under "req", and add them as found matches for
"req[extra]".
The typing module has been available since Python 3.5. Guarding the
import has been unnecessary since dropping Python 2.
Some guards remain to either:
- Avoid circular imports
- Importing objects that are also guarded by typing.TYPE_CHECKING
- Avoid mypy_extensions dependency
The stdlib module has been available since Python 3.5 and the
TYPE_CHECKING constant has been available since 3.5.2.
By using stdlib, this removes the need for pip to maintain its own
Python 2 typing compatibility shim.
Since 41a30089de, Candidate objects prepare their underlying
distribution eagerly on creation, so the error can be caught
deterministically to trigger backtracking.
This however has a negative side-effect. Since dist preparation involves
metadata validation, a remote distribution must be downloaded on
Candidate creation. This means that an sdist will be downloaded,
validated, and discarded (since its version is known to be incompatible)
during backtracking.
This commit moves version deduplication of candidates from indexes to
before the Candidate object is created, to avoid unneeded preparation.
Note that we still need another round of deduplication in FoundCandidates
to remove duplicated candidates when a distribution is already installed.
Use pyupgrade to convert simple string formatting to use f-string
syntax. pyupgrade is intentionally timid and will not create an f-string
if it would make the expression longer or if the substitution parameters
are anything but simple names or dotted names.
Since the "Requirement already satisfied" message is printed during
candidate preparation, instantiating the candidate multiple times result
in excessive logging during intensive backtracking. By caching the
already-installed candidates, each package is only prepared, and thus
only logged once.
This is done by catching InstallationError from the underlying
distribution preparation logic. There are three cases to catch:
1. Candidates from indexes. These are simply ignored since we can
potentially satisfy the requirement with other candidates.
2. Candidates from URLs with a dist name (PEP 508 or #egg=). A new
UnsatisfiableRequirement class is introduced to represent this; it is
like an ExplicitRequirement without an underlying candidate. As the
name suggests, an instance of this can never be satisfied, and will
cause eventual backtracking.
3. Candidates from URLs without a dist name. This is only possible for
top-level user requirements, and no recourse is possible for them. So
we error out eagerly.
The InstallationError raised during distribution preparation is cached
in the factory, like successfully prepared candidates, since we don't
want to repeatedly try to build a candidate if we already know it'd
fail. Plus pip's preparation logic also does not allow packages to be
built multiple times anyway.
