| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
When one keyring attempt fails, don't bother with more
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This makes https://github.com/pypa/pip/issues/8090 much less painful.
|
| |\ \ \ \ \ \ |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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 matches the behavior of pkg_resources.get_distribution(), which
this function intends to replace.
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
Document keyring support for index basic-auth
|
| | | | | | | | |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Always use UTF-8 to read pyvenv.cfg
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
|
| |/ / / / / / / / |
|
| |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
* Rename it to fit the fact that it no longer handle
fetching _not_ using lazy wheels
* Use self as the first parameter
* Unnest the checks with additional logs showing reason
when lazy wheel is not used
|
| |/ / / / / / / / / |
|
| | |_|_|_|_|_|/ /
|/| | | | | | | |
|
| |\ \ \ \ \ \ \ \
| |_|_|_|_|_|_|/
|/| | | | | | | |
Disable caching for range requests
|
| |/ / / / / / / |
|
| |\ \ \ \ \ \ \
| |_|_|_|/ / /
|/| | | | | | |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Removes dependence on `InstallRequirement`.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Reduces dependence on `InstallRequirement` being passed to
`_fetch_metadata`.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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 when we generate the InstallRequirement we set the link, these
must be the same.
Reduces dependence on Candidate.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Reduces dependence on Candidate.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Reduces dependence on Candidate (and Resolver (and Factory)).
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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`.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Returning a `Distribution` makes `_fetch_metadata` look more like
`_prepare_distribution`, in preparation for moving it there next.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
No change in behavior, we just want to unify "requirements processing"
and moving this function out is a prereq for moving `_fetch_metadata` in.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Since `_prepare` now internally validates that `_dist` isn't set, we
don't need to.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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).
|
| |\ \ \ \ \ \ |
|
| | | |_|_|_|/
| |/| | | | |
|
| | | | | | | |
|
