The call to get_installed_distributions() now passes all flags
excplicitly so they are more obvious and less likely to be misunderstood
in the future. The behavior also documented in the function docstring.
The search_distribution() helper function is renamed with a leading
underscore to make it clear that it is intended as a helper function to
get_distribution().
This keeps all knowledge about preparation and types of requirements in
`RequirementPreparer`, so there's one place to look when we're ready to
start breaking it apart later.
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.
This warning just needs to be traced in one place for all commands,
there's no need for the resolver to know about it. Moving the warning
out of the Resolver will make it easier to change how we provide the
option.
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).
This makes it more consistent with how error "summary" lines look.
eg:
IndexError: list index out of range
ModuleNotFoundError: No module named 'notamodule'
SVN has multiple distributions on Windows, e.g. SlikSVN, CollabNet. Some
of them suffix the version with a "-{distro}" part, which causes the
previous implementation to fail.
This patch removes that final part and make the version logic work.
The previous implementation uses pkg_resources.get_distribution(), which
does not canonicalize the package name correctly, and fails when
combined with pip's own get_distribution(), which does canonicalize
names. This makes InstallRequirement.check_if_exists() only use pip's
own canonicalization logic so different package name forms are matched
as expected.
Originally we would throw an `AttributeError` if a bad scheme key was
used. After refactoring we would throw a `KeyError`, which isn't much
better. Now we call out the wheel being processed, scheme key we didn't
recognize, and provide a list of the valid scheme keys. This would
likely be useful for people developing/testing the wheel.
Previously our wheel installation process allowed wheels which contained
non-conforming contents in a contained .data directory.
After the refactoring to enable direct-from-wheel installation, pip
throws an exception when encountering these wheels, but does not include
any helpful information to pinpoint the cause.
Now if we encounter such a wheel, we trace an error that includes the
name of the requirement we're trying to install, the path to the wheel
file, the path we didn't understand, and a hint about what we expect.
We explicitly propagate --use-feature options from req files upwards.
This is not strictly necessary for the option to be enabled, because
of the default value is a global list, but that implicit behaviour is
certainly accidental, so we make it explicit, with a test.
This patch adds support for `--use-feature` in requirements files
so that a project that wants all contributors using the same pip
features can specify it in the requirements file. For example, to ensure
a requirements file uses the new resolver:
```
--use-feature=2020-resolver
boto3
boto3==1.13.13
```
This is a new version of #8293.
Toward minimizing style changes in the overall PR diff, or toward
consistency with the future use of black (in cases where I wasn't sure
of a good way to minimize the diff).
This is a much better location for these errors, since they're in a much
more visible spot. We've had reports in the past of users missing these
messages, and changing where we present these warnings should help
resolve that issue.
We do lose the ability for an advanced user to potentially see the
warning and abort installation before the conflicts are introduced, but
given that we don't even pause for input, I don't think that's a strong
argument and neither do I view this as necessary.
The duplication of this code isn't really that bad, but saying
"pip check" makes it ambigous which file is relevant. Changing to
reference the exact filename makes this clearer.
This requirements format does not conform to PEP-508. Currently the
extras specified like this work by accident (because _strip_extras()
also parses them). The version checks end up being done with a
misparsed version '1.0[extra]' -- this is not changed in this commit.
Add deprecation warning and fix the corresponding resolver test. Add a
command line test.
Note that we really only check that the Requirement has SpecifierSet
with a specifier that ends in a ']'. A valid version number cannot
contain ']' and no wheels currently on pypi have versions ending in ']'.
Moving this value up from `_install_wheel` means that we do not need to
pass `req_description` anymore. This will also let us move our
entrypoint error handling around without worrying about losing the
context from the previous message.
Now we rely solely on the list of RECORD-like paths derived from the
filesystem, and can easily trade out the implementation for one that
comes from the wheel file directly.
Tzu-ping Chung
Pradyun Gedam
Nguyễn Gia Phong
Miro Hrončok
Chris Hunt
Pradyun Gedam
Pradyun Gedam
Stéphane Bidoul
Oliver Mannion
Andy Freeland
Jussi Kukkonen
Devesh Kumar Singh