Since the new packaging has types, it includes a py.typed. No harm in
including this in our package, and it may facilitate debug tool usage on
an installed pip by signaling that pip._vendor.packaging is
type-annotated.
Separately test should_build_for_wheel_command
and should_buid_for_install_command.
The tests are simpler and this open the door
for reasoning about both functions independently.
The only purpose of _collect_buildset is now
to compute the cache directory to use
for a given requirements. This is better
computed one by one in the build loop.
Actual installation has been using the wheel file directly for some
time. The last piece that required an unpacked wheel was metadata. Now
that it uses the wheel file directly, we can remove the unpacking after
build.
We now extract all metadata files from the wheel directly into memory
and make them available to the wrapping pkg_resources.Distribution via
the DictMetadata introduced earlier.
pkg_resources.Distribution classes delegate to the IMetadataProvider
implementation provided at construction. This is the one we'll use for
adapting a ZipFile to pkg_resources.DistInfoDistribution.
In order to parse metadata from wheel files directly we want to reuse
parse_wheel. Moving it out helps avoid creating an unnecessary
dependence on operations.install.wheel.
Previously we were copying an existing wheel to a file with a
different distribution name. When using stricter metadata parsing this
would fail, so now we use a more conformant dummy wheel function.
shared_data avoids copying the entire data directory, so use it in cases
where we know pip won't have any opportunity to edit the data files
(where we're passing tmpdir for --find-links).
Any test using --find-links data.packages is potentially using several
packages. By copying specifically the packages we need, we can more
easily see the packages that each test depends on and avoid using the
`data` fixture.
This functions as a guard for the rest of our wheel-handling code,
ensuring that we will only get past this point if we have a wheel that
we should be able to handle version-wise.
We return a tuple instead of bundling up the result in a dedicated type
because it's the simplest option. The interface will be easy to update
later if the need arises.
First example of transitioning a directory-aware function to using a
zipfile directly. Since we will not need to maintain the unpacked dir
going forward, we don't need to worry about making wheel_dist_info_dir
"generic", just that the same tests pass for both cases at each commit.
To do this neatly we use pytest.fixture(params=[...]), which
generates a test for each param. Once we've transitioned the
necessary functions we only need to replace the fixture name and remove
the dead code.
Since zips don't typically contain directory entries, we want to
only operate on files. Adding files to the .dist-info tests means we
will be able to reuse them for both cases, while they coexist.