More verbose explanation why "Could not find a version that satisfies the requirement"

[stdedos]

Environment

(venv-test) ~/pySAML2/example # pip --version
pip 10.0.1 from /root/pySAML2/example/venv-test/lib/python3.6/site-packages/pip (python 3.6)
(venv-test) ~/pySAML2/example # python --version
Python 3.6.8
(venv-test) ~/pySAML2/example # cat /etc/alpine-release 
3.9.0
(venv-test) ~/pySAML2/example # 

Description

I have spent hours trying to debug, what does this mean:

(venv-test) ~/pySAML2/example # pip install -r requirements.txt  --index-url https://pypi.python.org/simple/
Looking in indexes: https://pypi.python.org/simple/
Looking in links: https://pypi.python.org/simple/
Collecting mako (from -r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/f9/93/63f78c552e4397549499169198698de23b559b52e57f27d967690811d16d/Mako-1.0.10.tar.gz (460kB)
    100% |████████████████████████████████| 460kB 11.8MB/s 
Collecting cherrypy (from -r requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/aa/0e/4e353c47789ccb50130a44e765dae55b3e85abca01ff21930533ab36afc9/CherryPy-18.1.1-py2.py3-none-any.whl
Collecting pysaml2<5.0.0,>=4.7.0 (from -r requirements.txt (line 3))
  Downloading https://files.pythonhosted.org/packages/7b/20/df88d00a563fe437e9e03cf1b02927b47cea2fb5ed9d696c2820c53d7657/pysaml2-4.7.0-py2.py3-none-any.whl (335kB)
    100% |████████████████████████████████| 337kB 18.3MB/s 
Collecting MarkupSafe>=0.9.2 (from mako->-r requirements.txt (line 1))
  Using cached https://files.pythonhosted.org/packages/b9/2e/64db92e53b86efccfaea71321f597fa2e1b2bd3853d8ce658568f7a13094/MarkupSafe-1.1.1.tar.gz
Collecting cheroot>=6.2.4 (from cherrypy->-r requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/3e/50/840039a5350b54fb8efbc3b26c6e4244c9ca24c49ad84fe1f57b1f79ff7d/cheroot-6.5.5-py2.py3-none-any.whl
Collecting portend>=2.1.1 (from cherrypy->-r requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/54/18/d288ef3cfcaac40c9c3674d92ef8313bf137deeced810d60d9722c0a327a/portend-2.4-py2.py3-none-any.whl
Collecting more-itertools (from cherrypy->-r requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/b3/73/64fb5922b745fc1daee8a2880d907d2a70d9c7bb71eea86fcb9445daab5e/more_itertools-7.0.0-py3-none-any.whl
Collecting zc.lockfile (from cherrypy->-r requirements.txt (line 2))
Collecting pytz (from pysaml2<5.0.0,>=4.7.0->-r requirements.txt (line 3))
  Using cached https://files.pythonhosted.org/packages/3d/73/fe30c2daaaa0713420d0382b16fbb761409f532c56bdcc514bf7b6262bb6/pytz-2019.1-py2.py3-none-any.whl
Collecting defusedxml (from pysaml2<5.0.0,>=4.7.0->-r requirements.txt (line 3))
  Using cached https://files.pythonhosted.org/packages/06/74/9b387472866358ebc08732de3da6dc48e44b0aacd2ddaa5cb85ab7e986a2/defusedxml-0.6.0-py2.py3-none-any.whl
Collecting cryptography>=1.4 (from pysaml2<5.0.0,>=4.7.0->-r requirements.txt (line 3))
  Using cached https://files.pythonhosted.org/packages/07/ca/bc827c5e55918ad223d59d299fff92f3563476c3b00d0a9157d9c0217449/cryptography-2.6.1.tar.gz
  Could not find a version that satisfies the requirement cffi!=1.11.3,>=1.8 (from versions: )
No matching distribution found for cffi!=1.11.3,>=1.8
(venv-test) ~/pySAML2/example # 

While I was able to:

• Run this in a separate system (Ubuntu 16.04)
• With different python3 versions
• Find the required packages (on a manual https://pypi.org/simple/cffi/ search)
• Arch was compatible
• I was able to manually install https://files.pythonhosted.org/packages/93/1a/ab8c62b5838722f29f3daffcc8d4bd61844aa9b5f437341cc890ceee483b/cffi-1.12.3.tar.gz#sha256=041c81822e9f84b1d9c401182e174996f0bae9991f33725d059b771744290774, and yet, pip was pulling my leg: [1]

(venv-example) ~/pySAML2/example # pip install -r /root/pySAML2/example/requirements.txt --extra-index-url https://pypi.python.org/simple/
Looking in indexes: https://pypi.python.org/simple/
Looking in links: https://pypi.python.org/simple/
Collecting mako (from -r /root/pySAML2/example/requirements.txt (line 1))
  Downloading https://pypi.python.org/simple//mako/Mako-1.0.10.tar.gz (460kB)
    100% |████████████████████████████████| 460kB 143kB/s 
Collecting cherrypy (from -r /root/pySAML2/example/requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/aa/0e/4e353c47789ccb50130a44e765dae55b3e85abca01ff21930533ab36afc9/CherryPy-18.1.1-py2.py3-none-any.whl
Collecting pysaml2<5.0.0,>=4.7.0 (from -r /root/pySAML2/example/requirements.txt (line 3))
  Downloading https://pypi.python.org/simple//pysaml2/pysaml2-4.7.0-py2.py3-none-any.whl (335kB)
    100% |████████████████████████████████| 337kB 166kB/s 
Collecting MarkupSafe>=0.9.2 (from mako->-r /root/pySAML2/example/requirements.txt (line 1))
  Using cached https://files.pythonhosted.org/packages/b9/2e/64db92e53b86efccfaea71321f597fa2e1b2bd3853d8ce658568f7a13094/MarkupSafe-1.1.1.tar.gz
Collecting cheroot>=6.2.4 (from cherrypy->-r /root/pySAML2/example/requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/3e/50/840039a5350b54fb8efbc3b26c6e4244c9ca24c49ad84fe1f57b1f79ff7d/cheroot-6.5.5-py2.py3-none-any.whl
Collecting more-itertools (from cherrypy->-r /root/pySAML2/example/requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/b3/73/64fb5922b745fc1daee8a2880d907d2a70d9c7bb71eea86fcb9445daab5e/more_itertools-7.0.0-py3-none-any.whl
Collecting portend>=2.1.1 (from cherrypy->-r /root/pySAML2/example/requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/54/18/d288ef3cfcaac40c9c3674d92ef8313bf137deeced810d60d9722c0a327a/portend-2.4-py2.py3-none-any.whl
Collecting zc.lockfile (from cherrypy->-r /root/pySAML2/example/requirements.txt (line 2))
  Using cached https://files.pythonhosted.org/packages/58/c2/d7c89bdad237b4b7837609172be3e8bf5630796c0020494a15b97ece8eb1/zc.lockfile-1.4.tar.gz
Collecting pyOpenSSL (from pysaml2<5.0.0,>=4.7.0->-r /root/pySAML2/example/requirements.txt (line 3))
  Using cached https://files.pythonhosted.org/packages/01/c8/ceb170d81bd3941cbeb9940fc6cc2ef2ca4288d0ca8929ea4db5905d904d/pyOpenSSL-19.0.0-py2.py3-none-any.whl
Collecting requests>=1.0.0 (from pysaml2<5.0.0,>=4.7.0->-r /root/pySAML2/example/requirements.txt (line 3))
  Using cached https://files.pythonhosted.org/packages/51/bd/23c926cd341ea6b7dd0b2a00aba99ae0f828be89d72b2190f27c11d4b7fb/requests-2.22.0-py2.py3-none-any.whl
Collecting six (from pysaml2<5.0.0,>=4.7.0->-r /root/pySAML2/example/requirements.txt (line 3))
  Using cached https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whl
Collecting cryptography>=1.4 (from pysaml2<5.0.0,>=4.7.0->-r /root/pySAML2/example/requirements.txt (line 3))
  Using cached https://files.pythonhosted.org/packages/07/ca/bc827c5e55918ad223d59d299fff92f3563476c3b00d0a9157d9c0217449/cryptography-2.6.1.tar.gz
  Could not find a version that satisfies the requirement cffi!=1.11.3,>=1.8 (from versions: )
No matching distribution found for cffi!=1.11.3,>=1.8
(venv-example) ~/pySAML2/example # pip list | grep cffi
cffi       1.12.3 

Something started stricking me, when I saw a whole lot of .tar.gz instead of -?py2.?py3-?????-????.whl files getting pulled

After searching the internet without avail, I found #3969 this, and then things started falling in place as to "why" my python so forcefully resisted installing https://files.pythonhosted.org/packages/5f/bf/6aa1925384c23ffeb579e97a5569eb9abce41b6310b329352b8252cee1c3/cffi-1.12.3-cp36-cp36m-manylinux1_x86_64.whl

Expected behavior

I would like to have a very precise indication as to "why" something "is not found".

pip clearly found the version and arch it wanted, it was just not happy with the manylinux1 "tag".

e.g. pip could've said:

  Could not find a version that satisfies the requirement cffi!=1.11.3,>=1.8 
Versions matching requirement "!=1.11.3,>=1.8": [x,y,z, ....] # Descending, truncating if output is too large? Some basic filtering first, THEN the version requirement?
Architectures matching (x86_64): x86_64
"Python Version" matching (p36): [cp36, cp36m]
Distributions matching (linux_x86_64, any): None

How to Reproduce

1. Get package from '...'
2. Then run '...'
3. An error occurs.

Output

# python3 -c "import wheel.pep425tags as w; print(w.get_supported())" | tr '\n' '\0' | sed -E 's/\),/),\n/g'
[('cp36', 'cp36m', 'linux_x86_64'),
 ('cp36', 'abi3', 'linux_x86_64'),
 ('cp36', 'none', 'linux_x86_64'),
 ('cp35', 'abi3', 'linux_x86_64'),
 ('cp34', 'abi3', 'linux_x86_64'),
 ('cp33', 'abi3', 'linux_x86_64'),
 ('cp32', 'abi3', 'linux_x86_64'),
 ('cp36', 'none', 'any'),
 ('cp3', 'none', 'any'),
 ('cp35', 'none', 'any'),
 ('cp34', 'none', 'any'),
 ('cp33', 'none', 'any'),
 ('cp32', 'none', 'any'),
 ('cp31', 'none', 'any'),
 ('cp30', 'none', 'any'),
 ('py3', 'none', 'linux_x86_64'),
 ('py36', 'none', 'any'),
 ('py3', 'none', 'any'),
 ('py35', 'none', 'any'),
 ('py34', 'none', 'any'),
 ('py33', 'none', 'any'),
 ('py32', 'none', 'any'),
 ('py31', 'none', 'any'),
 ('py30', 'none', 'any')]

[1]: I am considering if that would be a bug. What's pips deal, "not" accepting a self-compiled, pre-installed depenedency? Why would it "mandatorily" need to pull it as cffi-1.12.3-cp36-cp36m-manylinux1_x86_64.whl, and not be satisfied by "just" compiling it (or having "me" jump through hoops to make it appear in pip list)?

[stdedos]

I later found the -vvv output (#3642 (comment)). However, it is awfully verbose (as suggested by the -vvv) for tracking down "one" package refusing to install.

The "only two" reasons given were the:

it is not compatible with this Python
No sources permitted for cffi

[stdedos]

Related issues

• Error message when package isn't support by current python version leaves a lot to be desired #5915
• Pip doesn't work in pypy #177
• Redesigning pip's output (for install, wheel and download commands) #4649 (comment)

(?)

[uranusjr]

+1 to this, maybe we can take inspirations from the hash mismatch error. The most difficult parts are probably to draft out the appropriate messages to show in each scenario, and to correctly detect the scenarios (easier if the scenarios are lined out well in the previous part).

[cjerdonek]

However, it is awfully verbose (as suggested by the -vvv) for tracking down "one" package refusing to install.

I happened to write up a comment on another issue with an idea on addressing this: #6121 (comment)
Basically, the idea is to add a new pip tags command (in the sense of PEP 425 tags) that would let one do things like (1) view the effective tags given certain options (--python-version, --platform, etc), and (2) hone in and analyze individual filenames to see whether they would be accepted, and if not, why not.

[cjerdonek]

python3 -c "import wheel.pep425tags as w; print(w.get_supported())"

@stdedos pip uses a vendored version of pep425tags located at pip._internal.pep425tags. Do you get the same output for your above command if you use that?

[stdedos]

I would say I get (almost) the same output, yes (but I am not in front of a computer to verify at the moment)

[stdedos]

Yes, it is exactly the same (I have run that command already, but "a bit differently"):

import pprint; import pip._internal; pprint.pprint(pip._internal.pep425tags.get_supported())

[wontonst]

I am also facing this issue but I have a workaround

[one-matrix]

i have this problem too.
Could not find a version that satisfies the requirement platform-client-py3==1.0.313339+cf390f098ab2bb50edead56b4ce55da9d63b7010 (from versions: 1.0.293831+106a6f5da46f7096db2e3d07583c119ba598ccc3, 1.0.293834+50e61f1025c06bcd64826259c060b21b16c5942c, 1.0.301504+13fb751758e8dc8726756be8696a610f1f719bec)
ERROR: No matching distribution found for platform-client-py3==1.0.313339+cf390f098ab2bb50edead56b4ce55da9d63b7010

[mihaimaruseac]

+1 on this. Right now I am getting the following:

ERROR: Could not find a version that satisfies the requirement tf-estimator-nightly==2.1.0.dev2020022102 (from versions: ..., 2.1.0.dev2020022102)
ERROR: No matching distribution found for tf-estimator-nightly==2.1.0.dev2020022102

As you see, the package already shows up in the versions listed

[LinnaViljami]

I ran into the same problem, it occurred only when I ran commands from my Docker image (or Dockerfile). Finally many hours later I managed to solve it by updating my python intepreter. Pointed out that my pip-package required python>=3,7 but my Docker image was using python 3.6.

Tip: To check out if you have similar problem, just check pip package requirements and your python version. Private pip package intepreter requirements are wrote down inside setup.py or setup.cfg. Public pip packages are usuially hosted in pypi.org where you can just check intepreter requirements with your browser. To check your python intepreter version just write for example python --version or python3 --version in your console

[pradyunsg]

We definitely want to improve this -- the bit that needs discussion is how we'd improve this.

The most common case seems to be... mismatching platforms / python-requires.

[EdSeymore]

As a follow up to #10501
which has been closed pointing to this item:

I get the subject message when following procedure from
https://docs.nvidia.com/deeplearning/frameworks/install-tf-jetson-platform/index.html
for the terminal cmd:
sudo pip3 install --pre --extra-index-url https://developer.download.nvidia.com/compute/redist/jp/v46 tensorflow
sudo apt-cache show nvidia-jetpack yields:
Package: nvidia-jetpack Version: 4.6-b199 Architecture: arm64

[pfmoore]

Well, for a start, that URL https://developer.download.nvidia.com/compute/redist/jp/v46 gives a 404 for me...

[EdSeymore]

OK, we are making progress. If that is what pip sees also,
that is what it should report back to the user.

[pfmoore]

It shows this, but only in verbose output (-vv). This is because we don't want to report 404 errors in general - a package may only be served from a local index and not on PyPI, and we don't want to report 404s from PyPI in a perfectly normal situation.

Generally, if you get an unexpected result (in any tool, not just pip), enabling verbose or debug output is the recommended way of seeing what's going on, and it gives you the information you need here.

Yes, it might be possible to do better (retain the responses we got, and if we can't find any suitable candidates, check them to see if there's anything worth reporting). But that's a lot of work for a relatively rare situation. A PR would be welcome, but it's unlikely to be a priority for the pip developers in the immediate future.

[EdSeymore]

Very useful information. I was not aware of -vv.
I started from a one line instruction in a recently published book:
pip3 install tensorflow
and have spent 10 frustrating days trying to get that instruction to work.
Perhaps just adding that one hint to the message in question would have saved some time.

[pfmoore]

Getting the information correct in the book would also have helped, I guess 🙁 From what I can tell, tensorflow is a whole complicated ecosystem of its own, so you have my sympathy. As I said, though, a PR would be welcomed if there's an improvement you think might have helped with how we report the problem.

[pradyunsg]

sudo pip3 install --pre --extra-index-url developer.download.nvidia.com/compute/redist/jp/v46 tensorflow

Yea... To me, it looks like these docs are out of date; and the best folks to reach out to would be folks at NVIDIA. Sadly, I don't know what the best channel or mechanism to do so would be.

[EdSeymore]

I have resolved my issue with pip install error message:
I was using python3.8 in a virtual environment.
I switched to python3.6 in a virtual environment and
no error message.

Conclusion: the pip wheel definitions seem to be very restrictive.

My background is with IBM systems.
I prefer to always use the most recent stable versions of all packages.
This strategy does not seem to work in the ubuntu world.

Thanks again for all the help offered. The ubuntu world is full of very
helpful people who are doing a great job of making extremely useful
functions available for the human race. I suggest we also work on making
these systems more efficient by reducing the complexity by making all
packages upward compatible. My application written in C++ under windows
in 1996 stills run without modification because Windows, C++, and
Microsoft Foundation Classes retains the same API as in 1996.

[edmorley]

I think one of the UX issues here is that the same "Could not find a version that satisfies the requirement X" message is actually shown for two distinct scenarios:

1. No versions of the package exist for the specified version (ie: invalid/typoed version)
2. Versions of the package do exist for the specified version, but aren't compatible in some way (eg Python version/platform/...)

...and the current message reads as though it's saying (1) is always the case - and it requires knowing how Python packaging/PyPI/pip works to know that (2) is also a possibility.

This issue seems to be blocked on trying to come up with all the sub-permutations of scenario (2), and having precise error messages for each (eg listing Python version as the issue, and showing compatible versions).

However, I think most of the UX benefit could still be achieved via a simpler single generic message for scenario (2), that doesn't require as many design decisions or implementing tags parsing/analysis etc, and so be quicker to implement. This could initially just be a stop-gap, but we might find it actually solves the problem well enough that we don't need the more complex solution.

Example generic error message for (2):
"Version X of the package was found, but is not compatible with the current environment. In most cases this means it requires a different Python version or Operating System."

[edmorley]

Ah I see the Python versions case specifically is now handled, via #9708. Example output (when using Python 3.7 and a package that has dropped support for 3.7):

$ pip install ipython==8.5.0
ERROR: Ignored the following versions that require a different python version: 8.0.0 Requires-Python >=3.8; 8.0.0a1 Requires-Python >=3.8; 8.0.0b1 Requires-Python >=3.8; 8.0.0rc1 Requires-Python >=3.8; 8.0.1 Requires-Python >=3.8; 8.1.0 Requires-Python >=3.8; 8.1.1 Requires-Python >=3.8; 8.2.0 Requires-Python >=3.8; 8.3.0 Requires-Python >=3.8; 8.4.0 Requires-Python >=3.8; 8.5.0 Requires-Python >=3.8
ERROR: Could not find a version that satisfies the requirement ipython==8.5.0 (from versions: 0.10, 0.10.1, 0.10.2, 0.11, 0.12, 0.12.1, 0.13, 0.13.1, 0.13.2, 1.0.0, 1.1.0, 1.2.0, 1.2.1, 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.3.1, 2.4.0, 2.4.1, 3.0.0, 3.1.0, 3.2.0, 3.2.1, 3.2.2, 3.2.3, 4.0.0b1, 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.1.0rc1, 4.1.0rc2, 4.1.0, 4.1.1, 4.1.2, 4.2.0, 4.2.1, 5.0.0b1, 5.0.0b2, 5.0.0b3, 5.0.0b4, 5.0.0rc1, 5.0.0, 5.1.0, 5.2.0, 5.2.1, 5.2.2, 5.3.0, 5.4.0, 5.4.1, 5.5.0, 5.6.0, 5.7.0, 5.8.0, 5.9.0, 5.10.0, 6.0.0rc1, 6.0.0, 6.1.0, 6.2.0, 6.2.1, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 7.0.0b1, 7.0.0rc1, 7.0.0, 7.0.1, 7.1.0, 7.1.1, 7.2.0, 7.3.0, 7.4.0, 7.5.0, 7.6.0, 7.6.1, 7.7.0, 7.8.0, 7.9.0, 7.10.0, 7.10.1, 7.10.2, 7.11.0, 7.11.1, 7.12.0, 7.13.0, 7.14.0, 7.15.0, 7.16.0, 7.16.1, 7.16.2, 7.16.3, 7.17.0, 7.18.0, 7.18.1, 7.19.0, 7.20.0, 7.21.0, 7.22.0, 7.23.0, 7.23.1, 7.24.0, 7.24.1, 7.25.0, 7.26.0, 7.27.0, 7.28.0, 7.29.0, 7.30.0, 7.30.1, 7.31.0, 7.31.1, 7.32.0, 7.33.0, 7.34.0)
ERROR: No matching distribution found for ipython==8.5.0

The case I saw more recently that still had confusing UX, was for a platform mismatch (a user trying to install a Windows package on Linux):
moneymeets/python-poetry-buildpack#49

[pfmoore]

was for a platform mismatch

That seems pretty rare - it means there's no sdist and no wheel for that platform. Unless you use --no-binary, or you're using an index that doesn't include sdists (the latter seems to be the case in the linked issue), you won't see this error (you might get a build failure, of course, but that's different...)

So while I could see the advantage in a clearer message, I don't think it would matter as often as you'd think at first.

[edmorley]

I agree the platform case will be rare, and so low priority.

[vorburger]

#4228, #7565 and #8831 (and the broader #10421) look like related issues to this issue which perhaps could be duplicated to this?

[uranusjr]

I’m going to just close this in favour of #10421. This specific error message comes from the legacy resolver and is not going to be improved upon. The newer issue provides more relevant context toward the issue in its current state, against the current resolver implementation.