A boolean flag is simpler to reason about than a complex type like
`conflicts_with`.
In all of these situations `conflicts_with` was being assigned a
non-None value and only being checked for truthyness, so a bool is
sufficient to capture the required usages.
InstallRequirement.uninstall doesn't actually use conflicts_with, so
don't log it. Instead we output the requirement name so we still have
something that looks like a heading before indenting the log, and log
what we actually uninstall inside the function.
This will also enable us to get rid of conflicts_with.
This makes InstallRequirement simpler and overall makes it easier to
track how the parts of InstallRequirement are being used for the phases
of package processing.
This will be home to Dowloader, Download, and associated helper
functions. Since this is an abstraction over PipSession, it makes
sense to keep these functions in a separate module.
Also move a helper function here from operations.prepare.
When we factor out tests these will be needed in both sets, and it's
easier to refactor tests later if we avoid creating a dependency between
test files.
This aligns it with wheel installation and reinforces that it is the
very last thing that happens before we return (so we can potentially
refactor it out later).
Previously InstallRequirement.uninstall was using
InstallRequirement.check_if_exists, which is a very overloaded
function with several callers that operate at different phases in
pip processing, not to mention that it mutates InstallRequirement itself.
Now we don't use that function for InstallRequirement.uninstall.
There should be no behavior change here.
This helps in several ways:
1. makes it easier to test the correct behavior of wheel installation via
`install_unpacked_wheel` independent of `InstallRequirement`
2. is easier to understand, since `install_unpacked_wheel` itself should
know which Wheel version(s) it supports
3. reduces the scope of `check_compatibility` and `wheel_version`, which
will make it easier to move `wheel` to `operations.install.wheel`
Pip 20 changes the cache key format to include the
interpreter name. To avoid invalidating all existing caches,
we continue using existing cache entries that were computed
with the legacy algorithm. This should not regress issue #3025
because wheel cached in such legacy entries should have
the python implementation tag set.
Make sure ``pip wheel`` never outputs pure python wheels with a
python implementation tag. Better fix/workaround for
`#3025 <https://github.com/pypa/pip/issues/3025>`_ by
using a per-implementation wheel cache instead of caching pure python
wheels with an implementation tag in their name.
Fixes#7296
This is a more appropriate place for the function, since it is more
related to tags than wheels, and will make it easier to refactor Wheel
into its own module.
Moving installation into this class would add complexity but only to
service a single caller (InstallRequirement). Better to keep the Wheel
representation, which is used in several places, small and focused and
installation can be moved to its own module.
