"getting files" is one of the places that requires files to be on disk.
By extracting this out of `clobber` we can make it simpler and then
trade it out for a zip-based implementation.
Hiding the file-specific implementation we currently use will let us
trade out the implementation for a zip-backed one later. We can also use
this interface to represent the other kinds of files that we have to
generate as part of wheel installation.
We use a Protocol instead of a base class because there's no need for
shared behavior right now, and using Protocol is less verbose.
By removing this dependency of the "file installation" part of `clobber`
on the "file finding" part of `clobber`, we can more easily factor out
the "file installation" part.
Dropping the top-level directory creation allows us to make the
processing completely dependent on files to be installed, and not on the
top-level directory they happen to be installed in.
We already create the parent directory in the loop below, so this call
should be redundant for files that get installed.
This handles:
* Sub-processes within unit tests (thanks pytest-cov)
* Our pytest-fixture-based virtual environments and subprocesses
therein
* Running with xdist (e.g. `-n auto`)
* Combining results from all of the above using paths rooted with
`src/pip/*`
This doesn't handle:
* Platform-specific branches
* Python 2
* CI integration
Similar to our previous test refactoring, this removes the usage of
`--home` from the test command.
"Overriding" in the original test meant "placed after" in the
command-line arguments, which makes sense because setuptools will use
the last argument passed.
The current test depends on passing `--home` to `--install-option`.
Since we would like that to fail, we need to use another argument. None
of the other possible arguments have a visible side-effect, so we just
write the provided arguments to a file and check that in the test.
For some time we have not needed to pre-emptively unpack wheels as part
of metadata processing, but kept the existing logic because the
behavior would start to diverge more for different package types. In
this case, though, removing the special cases for wheels makes this
logic a bit simpler, so it is worth doing.
This check only applies to explicit requirements since we avoid
downloading the dist from finder altogether when there is a matching
installation (although the check wouldn’t change the behaviour in that
case anyway).
We can do this when we build the `ExplicitRequirement` instead, like how
we did for `SpecifierRequirement`, but that would require us to resolve
the direct requirement’s version eagerly, which I don’t want to.
The implemented approach checks the version only after resolution, at
which point the distribution is already built anyway and the operation
is cheap.