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.
Unnecessary since dropping Python 2 support. In Python 3, `__ne__`
defaults to the opposite of of `__eq__`.
https://docs.python.org/3/reference/datamodel.html#object.__ne__
> For `__ne__()`, by default it delegates to `__eq__()` and inverts the
> result unless it is `NotImplemented`.
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.
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.
The fact that all of this functionality can be put in terms of the
`RequirementPreparer` indicates that, at least at this point, this is
the cleanest place to put this functionality.
These are things we know will be true because of the existing wheel
processing. In the future we may delegate the extraction of these to the
LinkCandidate itself so it doesn't have to be an assertion.
We happen to know that this is the same treatment that gave us `_name`
and `_version` for Wheels in the first place (in `LinkEvaluator`). It's not
ideal, however the metadata consistency check that occurs in `Candidate`
after creation of a `Distribution` guards us against any deviation in
the name and version during our processing.
Reduces dependence on Candidate.
Since wheels can't be editable, we can move this into LinkCandidate,
closer to `RequirementPreparer.prepare_linked_requirement` into which we
want to integrate `_fetch_metadata`.
Instead of an early return, we fall through to the existing check at the
end of this function. This aligns our treatment of `_fetch_metadata` and
`_prepare_distribution`.
Since `_prepare` is called in two places, we preserve the
`if self._dist is not None` protection above the new call to
`_fetch_metadata`. The second `if` in `_prepare` handles the early
return required when processing a lazy wheel.
Now that `_dist` is only set on success, we can use it to guard against
repeated execution instead of `_prepared`. As a result there are now only
two possible outcomes for calling `dist`:
1. `_dist` set and returned - lazy and non-lazy req
2. `_dist` not set and exception raised - bad lazy or bad non-lazy req
Previously a call to `_fetch_metadata` could result in several possible
outcomes:
1. `_dist` set, `_provided` not set, dist returned - for lazy wheels
2. `_dist` set, `_provided` not set, exception - for bad lazy wheels
3. `_dist` not set, `_provided` not set, exception - for non-lazy req
exceptions
4. `_dist` set, `_provided` not set, exception - for bad non-lazy reqs
5. `_dist` set, `_provided` set, dist returned - for non-lazy reqs
and probably more.
Our intent is to use `_dist` being set as the indicator of "this
requirement has been fully processed successfully" and discard
`_prepared`, since we don't actually rely on any of the other states
(they simply lead to a failure or in the future a retry).
Paul Moore
Pradyun Gedam
Tzu-ping Chung
Stéphane Bidoul
Harutaka Kawamura
Stéphane Bidoul
Max W Chase
Stefano Rivera
Jon Dufresne
Pradyun Gedam
Chris Hunt
Nguyễn Gia Phong