Feature request: "none of the wheel's tags match" should show what doesn't match

[jameshfisher]

What did you want to do?

I want to install tensorflow on my Intel Macbook running macOS 11.2. I ran:

brew install python@3.8
brew link --overwrite python@3.8
pip3 install tensorflow

Output

$ pip3 install tensorflow
ERROR: Could not find a version that satisfies the requirement tensorflow (from versions: none)
ERROR: No matching distribution found for tensorflow

With verbose (-v) output, I get:

$ pip3 install --upgrade -v tensorflow
...
  Skipping link: none of the wheel's tags match: cp27-cp27m-macosx_10_11_x86_64: https://files.pythonhosted.org/packages/90/cf/1d1e12f9f39b6a0ed1c49792ef5ce7615dddc2ce7287fc83ede0dddb9b3c/tensorflow-0.12.0rc0-cp27-cp27m-macosx_10_11_x86_64.whl#sha256=feaf06c7df5c0a480654bf1f38dd4d3b809c7315502a7d9f295033f9d2bd9b13 (from https://pypi.org/simple/tensorflow/)
... OMITTING EXTREMELY LONG LIST OF WHEELS ...
  Skipping link: none of the wheel's tags match: cp38-cp38-win_amd64: https://files.pythonhosted.org/packages/ad/fc/fccaa149d7ccc165de01d62d19e5e9492e87ad23a7106f6dfe132800ca6f/tensorflow-2.4.1-cp38-cp38-win_amd64.whl#sha256=eedcf578afde5e6e69c75d796bed41093451cd1ab54afb438760e40fb74a09de (from https://pypi.org/simple/tensorflow/)

It's not very clear why each wheel is skipped. Instead of seeing:

Skipping link: none of the wheel's tags match: cp27-cp27m-macosx_10_11_x86_64:

I would like to see something that explains what doesn't match, like:

Skipping link: the wheel's `platform` tag `macosx_10_11` is incompatible with current platform `macosx_11_2`

(This is my current theory: I'm running macOS 11.2, but no packages exist for this. I want the pip output to be more explicit, to confirm this theory.)

Additional information

• Related issue reported at "No matching distribution found for tensorflow" when installing with pip on macOS 11 tensorflow/tensorflow#47205
• Here is the entire stdout from pip3 install --upgrade -v tensorflow: pip_output.txt

[jameshfisher]

So, surprisingly, pip DOES find a matching wheel when using virtualenv! The wheel tensorflow-2.4.1-cp38-cp38-macosx_10_11_x86_64.whl, with standard pip3 from Homebrew, is rejected with "none of the wheel's tags match", but with virtualenv, I get the output:

Found link https://files.pythonhosted.org/packages/2f/33/4b330de553d80ae6fa123ec9aee90ee7d679d297b1595c9c6ce2b3c7a967/tensorflow-2.4.1-cp38-cp38-macosx_10_11_x86_64.whl#sha256=4a04081647b89a8fb602895b29ffc559e3c20aac8bde1d4c5ecd2a65adce5d35 (from https://pypi.org/simple/tensorflow/), version: 2.4.1

It then goes on to install this wheel.

So now there are two mysteries:

• Why does pip3 under virtualenv install tensorflow-2.4.1-cp38-cp38-macosx_10_11_x86_64.whl, despite my OS being version 11.2 rather than 10.11? Shouldn't these be incompatible?
• Why does pip3 from Homebrew fail to match this wheel, if not due to the OS? And why won't it give me more specific information about what failed to match, so that I can debug it?

[pfmoore]

I suggest running pip3 debug --verbose for each invocation and comparing the supported compatibility tags. That will likely show you a difference. Why you're getting a difference will remain a question, but I'd suspect some sort of patching of pip by homebrew as an initial place to look. Do homebrew unbundle pip?

[jameshfisher]

@pfmoore well now, that's interesting! The pip3 from brew install python@3.8 has a list of compatible tags that only includes macosx_11:

$ pip3 debug --verbose | grep -E -o 'macosx_\d+_\d+' | sort | uniq
macosx_11_0
macosx_11_1
macosx_11_2

Whereas the pip3 from virtualenv includes macosx_10:

$ pip3 debug --verbose | grep -E -o 'macosx_\d+_\d+' | sort | uniq
macosx_10_10
macosx_10_11
macosx_10_12
macosx_10_13
macosx_10_14
macosx_10_15
macosx_10_16
macosx_10_4
macosx_10_5
macosx_10_6
macosx_10_7
macosx_10_8
macosx_10_9
macosx_11_0

And I found the reason: #9138 changes pip to accept macosx_10 when running on macOS 11, merged in pip 20.3, but pip from brew install python@3.8 is only version 20.2.4.

So I think this solves my specific issue - thanks! Now for the more general point: if pip had said none of the wheel's tags match (run pip debug --verbose to show compatible tags), I could probably have debugged this without support. Would you accept a PR that changes this wording?

[uranusjr]

macOS 11.2 is backwards compatible, so a macosx_10_11_x86_64 wheel should be considered compatible. The virtualenv’s pip is behaving correctly. Since the pip you get in Homebrew is distributed by Homebrew, maybe they made some patches that breaks the logic.

[pfmoore]

Now for the more general point: if pip had said none of the wheel's tags match (run pip debug --verbose to show compatible tags), I could probably have debugged this without support. Would you accept a PR that changes this wording?

Yep, that sounds like a useful change :-)

[uranusjr]

Ah, I recall this was actually fixed just before macOS 11 was announced (contribution made by an Apple employee), because pip (actually packaging) assumed macOS 11 would have been incompatible with Mac OS X (aka macOS 10). So Homebrew’s pip is probably just not new enough (20.2 was released in April 2020, before Big Sur’s annoucement).

[pradyunsg]

The reason for the mismatch is the different pip versions. 20.3.4 and 21.0 have a packaging update that fixed the wheel tags issue for macos tags.