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.
User-specified constraints only contain the project name without extras,
but a constraint a project A would also apply to A's extra variants.
This introduces a new project_name property on Requirement and Candidate
classes for this lookup.
Otherwise the test_install_distribution_union_with_versions test can end
up with either:
Cannot install localextras[bar] 0.0.2 and localextras[baz] 0.0.1 because these package versions have conflicting dependencies.
or
Cannot install localextras[baz] 0.0.2 and localextras[bar] 0.0.1 because these package versions have conflicting dependencies.
find_matches() is modified to return a special type that implements
the sequence protocol (instead of a plain list). This special sequence
type tries to use the installed candidate as the first element if
possible, and only access indexes when the installed candidate is
considered unsatisfactory.
