As with cpython_tags and compatible_tags, we assume this function covers
our use cases in the no-argument case and will customize our arguments
for it in a few steps.
We assume this function improves the status quo over the current
`_cpython_tags`, so we use it when no arguments need to be customized.
Since `packaging.tags` has its own tests and derives defaults
differently than pep425tags, we also remove the applicable tests that
were testing against the result of a plain call to
`pep425tags.get_supported()`.
We only call this function when the user or platform-provided
implementation is "cp", so we can inline the literal in place of the
parameter. This will make refactoring easier.
We assume this function improves on our existing behavior, so use it
as-is. We will customize the arguments over the next few commits.
Since packaging.tags internally calculates platforms when not provided,
we skip the tests which patch functions assuming that manylinux
compatibility determination depends on them.
Since `_compatible_tags` is the function that will be responsible for
generating the non-interpreter-specific tags, we remove the
corresponding sections from `_cpython_tags` and `_generic_tags`. The
resulting tags in `get_supported` are equivalent because these were
the last tags to be computed in those functions, and `_compatible_tags`
is executed after them (so any non-duplicate tags it produces will be
last).
To reinforce the reponsibility of `_compatible_tags` we also remove the
abi-related tag generation, which is already handled in `_cpython_tags`
and `_generic_tags`.
Since these functions are copies of the existing code, there is no
behavior change except each tag will now be present 3 times. To
accommodate this we remove all but the first duplicate tag from the
set of all tags.
We put `_compatible_tags` last because it will provide the lowest
priority tags. The order of `_cpython_tags` and `_generic_tags`
here is not significant - when we start customizing them we will
introduce a condition so that they are mutually exclusive.
packaging.tags provides a simple `sys_tags` function for getting
applicable tags for the running interpreter, but it does not allow
customization of arguments.
packaging.tags provides three functions for getting custom tags:
1. `cpython_tags` - for CPython only
2. `generic_tags` - for any non-CPython Python implementation
3. `compatible_tags` - tags that are not specific to an interpreter
implementation
Since pip allows users to provide explicit impl, platform, abi, and
version, we have to use these functions.
`cpython_tags` and `generic_tags` are mutually exclusive, and return tags
that are the highest priority. These capture the most specific tags.
`compatible_tags` are always applicable, and a lower priority since they
may just be compatible with e.g. the Python language version, but lack
any optimizations available in the interpreter-specific tags.
To be able to do a meaningful comparison between our current
implementation and the above functions, we need to segment the pip code
into pieces that look like them.
To that end, we now have copies of the current `get_supported` function,
one for each of the functions provided by packaging.tags, and will walk
through converting them to rely on packaging.tags. For each
simplification step, if desired, we can compare the implementation in
the packaging.tags function with what we're replacing in pip.
Specifically, for each function in turn, we will:
1. Refactor it locally, taking into account its new, more limited,
responsibilities
2. Introduce the packaging.tags function for the case where there are no
custom arguments provided
3. Customize arguments one-by-one and delegate to the packaging.tags
function
4. When there is no pip-specific logic left, remove the intermediate
function and use the packaging.tags function directly in
`get_supported`
In the end all these functions will be gone again and we'll be left with
an implementation that relies solely on the tag generation in
packaging.tags.
This is the standard type used by packaging.tags. Making this change
throughout the code lets us start switching over to using its
tag-generating functions in get_supported().
We also get rid of a test, since it was superseded by `__str__` in
packaging.tags.Tag.
This will allow us to have CI running concurrently on multiple PRs,
since we get 30 parallel jobs on Azure Pipelines but only 1 on AppVeyor.
We have parameterized --use-venv since AppVeyor was using it, but Azure
Pipelines was previously not.
This reduces the amount of code we have to manage.
interpreter_name is calculated differently, defaulting to the
long name of the interpreter rather than "cp", but that is more
conformant.
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.
