Use packaging.tags for doing compatible wheel tag calculation #7354
Conversation
|
You can probably do the following, to make the vendoring work properly. diff --git a/tools/automation/vendoring/__init__.py b/tools/automation/vendoring/__init__.py
index 1c2ae3a6..a77e9e58 100644
--- a/tools/automation/vendoring/__init__.py
+++ b/tools/automation/vendoring/__init__.py
@@ -128,6 +128,7 @@ def vendor(ctx, vendor_dir):
)
remove_all(vendor_dir.glob('*.dist-info'))
remove_all(vendor_dir.glob('*.egg-info'))
+ remove_all(vendor_dir.glob('*/py.typed'))
# Cleanup setuptools unneeded parts
(vendor_dir / 'easy_install.py').unlink() |
6878a93 to
8de85bb
Compare
|
Hello! I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the |
8de85bb to
cf52515
Compare
d57eb4a to
72432af
Compare
|
Test failure would be fixed by #7395. |
72432af to
3601c28
Compare
3601c28 to
6731511
Compare
|
Updated for latest commit, but had to update vendoring script locally to work around pypa/flit#298. |
|
Hello! I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the |
6731511 to
56ee682
Compare
|
Rebased on master and updated to use the latest commit on master for When |
56ee682 to
13c6934
Compare
Since this function is only called for non-CPython interpreters, the abi3-related branches are not relevant.
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.
Now that we're fully using packaging.tags, everything in the supported list is already Tag. Further, since each function is responsible for its own set of non-overlapping tags, we can also remove the de-duplication.
Since we only call this function when platform is not None, we can drop one of the branches. This is the only place using our manylinux auto-deduction functions, so those can be removed next.
The remaining glibc-related functions are required to allow us to put the libc version in the pip user agent (for stats).
Previously, these were used when the user did not provide an explicit ABI. Now this is handled internally in `packaging.tags` (by `_cpython_abi` and `_generic_abi`).
Now handled internally in `packaging.tags` (in `_platform_tags`).
f146ee0 to
d7fda71
Compare
| # type: (str) -> Optional[str] | ||
| return sysconfig.get_config_var(var) | ||
|
|
||
|
|
||
| def version_info_to_nodot(version_info): |
There was a problem hiding this comment.
follow up: I suggest moving the call to be changed -- changing get_supported to allow for version to be None (and use this value in that case).
|
Indeed. This was a decently large chunk of work which required a fair bit of figuring out the right way, and I know that you've spent time and effort to make the PRs easy to review! Thanks @chrahunt for driving this and making it happen! |
Introduction
packaging.tagsprovides a simplesys_tagsfunction for getting applicable tags for the running interpreter, but it does not allow customization of arguments. Since pip allows users to provide explicit interpreter (e.g. "pp"), platform (e.g. "linux_x86_64"), abi (e.g. "abi3"), and version (e.g. "35"), we have to use a different interface.packaging.tags provides three functions for users that need to customize tag generation:
cpython_tags- for tags applicable to CPython onlygeneric_tags- for tags applicable to any non-CPython Python implementationcompatible_tags- for tags that are not specific to an interpreterimplementation
cpython_tagsandgeneric_tagsare mutually exclusive, and return tags that are the highest priority. These tags are the most specific.compatible_tagsare always applicable, and a lower priority since they may just be compatible with e.g. the Python language version, but lack optimizations available in compiled code available for a specific interpreter/ABI/platform.In this PR we remove most of our custom logic in
pip._internal.pep425tags, instead relying on these three functions frompackaging.tags.Approach
It's a given that we want to switch to
packaging.tagsfor calculating compatible wheel tags, but while doing that we have a few other goals:packaging.tagswith what is currently in pip so we can understand possible issues that may be raised laterTo satisfy 1, the PR is broken into small commits that should each be easy to recognize the literal changes of and confirm as equivalent or understand the scope of change. Each commit should pass lint checks and tests, which should reduce the number of trivial things that need to be worried about and ensure that all changes are self-contained.
To satisfy 2, we take an approach that transforms
pep425tagsinto something that looks closer topackaging.tagsbefore actually using the functions.For each of the 3 custom tags functions, we make a copy of
get_supported, then:get_supportedFollowing that, we remove unused utility methods, then in the end we're left with an implementation that relies solely on the tag generation in packaging.tags.
Fixes #6908.