Side note: the command is actually being run as part of a deployment tool, pulling from a requirements file, but tricks like downloading the correct packages and using --find-links or explicitly listing the local path in the requirements file still fail with the same error.

I was looking at PEP-600 and also concur that current behavior does not match my understanding of PEP-600.
My usecase: I will be running a package on a Linux platform that uses glibc 2.31. I'd like to download a wheel that will be compatible for this platform, so I'd want to run

python3 -m pip download -d /tmp/d --only-binary :all: --platform manylinux_2_31_x86_64 numpy==1.22.0

and expect that the latest compatible wheel is fetched.

cc: @pfmoore

If somone wants to see this addressed, we'd be happy to accept a PR for this (subject to the regular code review process).

The relevant file for this would be https://github.com/pypa/pip/blob/main/src/pip/_internal/utils/compatibility_tags.py, and I imagine that test improvements would be appreciated.

My usecase: I will be running a package on a Linux platform that uses glibc 2.31. I'd like to download a wheel that will be compatible for this platform, so I'd want to run [..] and expect that the latest compatible wheel is fetched.

A workaround is to specify all platforms that the target platform supports. Figuring out that list can be achieved using some variant of the below on the target-platform (and ignoring the message about not automatically parsing):

python -m pip debug --verbose | grep cp39-cp39 | awk -F- '{print $3}'

Folks, PEP-600 was accepted almost 3 years ago. Why does pip download not support this functionality yet? Looks like there's been some recent movement with PR #10894 but I do not understand the feet-dragging on this. As always I feel like the bad guy for wanting basic functionality out of pip download, but I can't imagine I'm the only one that wants to download packages for use in an offline foreign environment.

The workaround of listing each platform tag separately (2.5 through 2.28 in my case) is really inconvenient. Maybe if I were really fancy with my bash array skills it wouldn't be, but nothing immediate came to mind for passing all those options.

Sorry to post on an old bug, but I find myself in the impossible attempt to download wheels for a specific linux platform but different architecture and apparently this bug prevents me from composing a download command that would work.

python -m pip debug --verbose | grep many|grep py310
  py310-none-manylinux_2_38_aarch64
  py310-none-manylinux_2_37_aarch64
  ...
  py310-none-manylinux_2_17_aarch64
  py310-none-manylinux2014_aarch64

For latest version of pyyaml the only command that will succeed is pip download -vv -d dist/linux/x86_64 --platform=manylinux_2_17_x86_64 --only-binary=:all: --python-version=310 pyyaml==6.0.1

Unless I fully mention the manylinux_2_17_x86_64, I will not be able to download "whatever blend of manylinux for x86_64 is available.

The grep command above makes me believe that pip is trying ~20 names until it finds that one to be acceptable. Still, I see no way I can build the same fallback list when attempting to perform to call download.

To give some insights, I am trying to download full list of dependencies for two different platforms (arm and intel) while avoiding to run under qemu as that makes the process 10x slower, this being the preparatory task for building a dual-arch container image.

Basically I have the impression that --platform argument is so restrictive that it makes itself unpractical to use as it requires a perfect match.

#12466 It feels tangentially related (but a separate issue with pip download --platform)