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.
Originally we would throw an `AttributeError` if a bad scheme key was
used. After refactoring we would throw a `KeyError`, which isn't much
better. Now we call out the wheel being processed, scheme key we didn't
recognize, and provide a list of the valid scheme keys. This would
likely be useful for people developing/testing the wheel.
Previously our wheel installation process allowed wheels which contained
non-conforming contents in a contained .data directory.
After the refactoring to enable direct-from-wheel installation, pip
throws an exception when encountering these wheels, but does not include
any helpful information to pinpoint the cause.
Now if we encounter such a wheel, we trace an error that includes the
name of the requirement we're trying to install, the path to the wheel
file, the path we didn't understand, and a hint about what we expect.
This requirements format does not conform to PEP-508. Currently the
extras specified like this work by accident (because _strip_extras()
also parses them). The version checks end up being done with a
misparsed version '1.0[extra]' -- this is not changed in this commit.
Add deprecation warning and fix the corresponding resolver test. Add a
command line test.
Note that we really only check that the Requirement has SpecifierSet
with a specifier that ends in a ']'. A valid version number cannot
contain ']' and no wheels currently on pypi have versions ending in ']'.
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.
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.
Since this is the special part of this test. This gives us more
confidence that we're doing the right thing when removing the standalone
wheel file next.