This unifies the behavior of pip download for both legacy and new
resolvers. InstallRequirement.successfully_download is no longer needed
for this task and is thus retired.
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 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.
These are the only cases where backtracking can happen. This approach
also accounts for VCS requirements relying on the same ensure function
to do cloning :/
source_dir is only passed to the InstallRequirement constructor
in the case of editable requirements, and it is built from link,
which is also passed to the same constructor. So we let
InstallRequirement compute source_dir, to remove that burden
from call sites.
Since all directories are now globally-managed, we don't need to be
concerned with resetting the member values.
This will also let us remove several responsibilities from
RequirementSet, which will make integrating the new resolver easier.
Previously we were writing a delete marker file which is checked in
InstallRequirement.remove_temporary_source which is only invoked if the
user did not pass --no-clean (and a PreviousBuildDirError was not
raised). Since our TempDirectory machinery now respects these conditions
we can just wrap our source directory in that instead of using this
ad-hoc mechanism for tracking our delete preference.
This will let us clean up a lot of dead code that only existed for this
use case.
InstallRequirement.remove_temporary_source was already being called at
the end of processing (as part of RequirementSet.cleanup()), so this
doesn't change behavior - cleanup still happens right after the command
finishes.
Now we can refactor this to be globally managed, and it will have the
same behavior as it does currently (if there is any
PreviousBuildDirError it will not be cleaned up).
InstallRequirement only checks for a delete marker file in source_dir.
Since the result of ensure_build_location is set to source_dir (in
ensure_has_source_dir), and ensure_build_location returns a subdirectory
of the build_directory to which we write the delete marker file, then
this delete marker file is never used.
This untested function was only used in one place. Inlining it makes it
easier to see the symmetry between the writing of the delete marker file
in `ensure_build_location` and checking for it in
`remove_temporary_source`.
This removes one of usages of the overloaded `source_dir` member.
We know the local_file_path must be set at this point because it is set
in the only 3 places that wheels are added to InstallRequirement.
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 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`
Since self._ideal_build_dir is only either None or a string, we must
have always been returning from this function.
This goes back to pip 10.0.0, so this code has been dead for some time.
Previously we were adding arguments to install_options in response to
command-line parameters, which leads to spooky action at a distance.
Now we provide the arguments explicitly.
Why: There isn't any state being maintained, or multiple uses of the
metadata generator for a single requirement. The additional complexity
does not help in any significant manner.
Nguyễn Gia Phong
