Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to install manylinux1 wheel from manylinux1 docker image (Centos5) when a newer manylinux2010 wheel is available #6547

Closed
jcfr opened this issue May 27, 2019 · 10 comments
Labels
auto-locked Outdated issues that have been locked by automation type: support User Support

Comments

@jcfr
Copy link
Contributor

jcfr commented May 27, 2019

Environment

  • pip version: 19.1.1
  • Python version: 2.7.16, 3.4.10, 3.5.7, 3.6.8, 3.7.3
  • OS: Centos5, manylinux1

Description

Attempt to install a wheel from manylinux1 docker image (Centos 5) should successfully install an older manylinux1 wheel instead of trying to build the latest one from source that is only available for manylinux2010.

Expected behavior

If the following sdist and wheels are available:

cmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl
cmake-3.13.3.tar.gz
cmake-3.14.3-py3-none-manylinux2010_x86_64.whl
cmake-3.14.3.tar.gz
cmake-3.14.4-py3-none-manylinux2010_x86_64.whl
cmake-3.14.4.tar.gz

Trying to pip install cmake from a manylinux1 system (using python 3.6) should successfully install cmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl.

Additional remarks

  • Running pip install cmake<3.14 successfully install cmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl

  • Starting with cmake 3.14, we changed the tags of the binary wheel to be ABI independent, this was suggested by @njsmith in Add Python 3.8.0a2 manylinux#273 (comment) to avoid building one wheel per python release.

    • cmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl # specific to Python 3.7 ABI
    • cmake-3.14.4-py3-none-manylinux2010_x86_64 # platform specific but generic

How to Reproduce

  • (1) Download manylinux1_x86_64 image
docker pull quay.io/pypa/manylinux1_x86_64
  • (2). Start a shell
docker run --rm -ti quay.io/pypa/manylinux1_x86_64 bash
  • (3). Attempt to install cmake wheel
for PYBIN in /opt/python/*/bin; do
  echo "-----------------"
  output=$("${PYBIN}/pip" install cmake --verbose 2>&1 | grep "Running setup.py")
  [[ $output != "" ]] && echo "PROBLEM: pip is attempting to build sdist"
  ${PYBIN}/pip --version
  ${PYBIN}/python --version
done

Output

-----------------
PROBLEM: pip is attempting to build sdist
pip 19.1.1 from /opt/_internal/cpython-2.7.16-ucs2/lib/python2.7/site-packages/pip (python 2.7)
Python 2.7.16
-----------------
PROBLEM: pip is attempting to build sdist
pip 19.1.1 from /opt/_internal/cpython-2.7.16-ucs4/lib/python2.7/site-packages/pip (python 2.7)
Python 2.7.16
-----------------
PROBLEM: pip is attempting to build sdist
pip 19.1.1 from /opt/_internal/cpython-3.4.10/lib/python3.4/site-packages/pip (python 3.4)
Python 3.4.10
-----------------
PROBLEM: pip is attempting to build sdist
pip 19.1.1 from /opt/_internal/cpython-3.5.7/lib/python3.5/site-packages/pip (python 3.5)
Python 3.5.7
-----------------
PROBLEM: pip is attempting to build sdist
pip 19.1.1 from /opt/_internal/cpython-3.6.8/lib/python3.6/site-packages/pip (python 3.6)
Python 3.6.8
-----------------
PROBLEM: pip is attempting to build sdist
pip 19.1.1 from /opt/_internal/cpython-3.7.3/lib/python3.7/site-packages/pip (python 3.7)
Python 3.7.3

Detailed Output

$ /opt/_internal/cpython-3.6.8/bin/pip install "cmake" --verbose 2>&1 | grep -E "(link.+(py3|cp36).+manylinux.+86_64)|(link.+cmake.+tar.gz)"

[...]
    Found link https://files.pythonhosted.org/packages/45/c4/e69313ade2a3e992e7178744b0e56bdd8f23e79e15066a68cf490504beed/cmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl#sha256=fb60931c20bb8653d5c9d0ccb0ad0028804ece1a0797cb49222ee0358c8250c4 (from https://pypi.org/simple/cmake/), version: 3.13.3
    Found link https://files.pythonhosted.org/packages/72/7b/8d3d83f884283ddfc86ca407d10152d66b84dff5baf5ed4537c127f988cb/cmake-3.13.3.tar.gz#sha256=5925479027e7816b0d4bf6b145bf41a544cc33adad41b0bcb1501ce5701b006b (from https://pypi.org/simple/cmake/), version: 3.13.3
    Skipping link https://files.pythonhosted.org/packages/db/53/e4948f2b1e5487cdcdc116909f6b2747249c0d24c813071e191baedab386/cmake-3.14.3-py3-none-manylinux2010_x86_64.whl#sha256=778a79ee24e901f118ba07ec7d50602d13014e83c2d7823f6771cdef89fb0fa2 (from https://pypi.org/simple/cmake/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/5d/3c/879a83e4e29fe1b7b7581eb4d5067edf8f9a0adbae96050013593d706c3e/cmake-3.14.3.tar.gz#sha256=0c9a39c584279633dfd606f7f96862bf71407102363d9da72ce3172e1bc28847 (from https://pypi.org/simple/cmake/), version: 3.14.3
    Skipping link https://files.pythonhosted.org/packages/ab/b5/d83c2f95d4be1ee9f851e91fedfc943816cfad7940b101791d1b41d00eb3/cmake-3.14.4-py3-none-manylinux2010_x86_64.whl#sha256=d3cf88424c65b460767fb8281df8be7c61585bb9ea2cd71f6aaedacb9ff78fda (from https://pypi.org/simple/cmake/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/55/2a/021e5d8c03928ec7bad199d8a596ab5bc3811b116e40f6454891c3b5b821/cmake-3.14.4.tar.gz#sha256=bb22fbcba65cae40eadd4296e61e82ed586f94e55687e9a36cca4205038f8052 (from https://pypi.org/simple/cmake/), version: 3.14.4

Issue potentially related

@jcfr jcfr changed the title Failure to install manylinux1 wheel from manylinux1 when a newer manylinux2010 is available Failure to install manylinux1 wheel from Centos5 when a newer manylinux2010 wheel is available May 27, 2019
@jcfr jcfr changed the title Failure to install manylinux1 wheel from Centos5 when a newer manylinux2010 wheel is available Failure to install manylinux1 wheel from manylinux1 docker image (Centos5) when a newer manylinux2010 wheel is available May 27, 2019
@cjerdonek
Copy link
Member

To troubleshoot the "it is not compatible with this Python" log messages you're getting above, can you try running the following code on your system?

from pip._internal.pep425tags import get_supported
print('\n'.join('-'.join(x) for x in get_supported()))

This will tell you what tags pip is using to find matches against.

Also, here's another related issue: #6526

@cjerdonek cjerdonek added the S: needs triage Issues/PRs that need to be triaged label May 27, 2019
@jcfr
Copy link
Contributor Author

jcfr commented May 27, 2019

Thanks for the quick follow up 🙏

Here it is:

$ docker run --rm  \
  quay.io/pypa/manylinux1_x86_64 \
  /opt/python/cp37-cp37m/bin/python  -c \
  "from pip._internal.pep425tags import get_supported; \
   print('\n'.join('-'.join(x) for x in get_supported()))"
cp37-cp37m-manylinux1_x86_64
cp37-cp37m-linux_x86_64
cp37-abi3-manylinux1_x86_64
cp37-abi3-linux_x86_64
cp37-none-manylinux1_x86_64
cp37-none-linux_x86_64
cp36-abi3-manylinux1_x86_64
cp36-abi3-linux_x86_64
cp35-abi3-manylinux1_x86_64
cp35-abi3-linux_x86_64
cp34-abi3-manylinux1_x86_64
cp34-abi3-linux_x86_64
cp33-abi3-manylinux1_x86_64
cp33-abi3-linux_x86_64
cp32-abi3-manylinux1_x86_64
cp32-abi3-linux_x86_64
py3-none-manylinux1_x86_64
py3-none-linux_x86_64
cp37-none-any
cp3-none-any
py37-none-any
py3-none-any
py36-none-any
py35-none-any
py34-none-any
py33-none-any
py32-none-any
py31-none-any
py30-none-any

@cjerdonek
Copy link
Member

/opt/python/cp37-cp37m/bin/python

Just to be sure, that looks like a different pip from the one above you used to reproduce the error:

/opt/_internal/cpython-3.6.8/bin/pip install "cmake" --verbose 2>&1 ...

@jcfr
Copy link
Contributor Author

jcfr commented May 27, 2019

Good catch. I edited the original description to be consistent and mention 36 instead of 37.

The difference in path is explained by the fact /opt/python/cp36-cp36m/bin/python is a symlink:

$ docker run --rm    quay.io/pypa/manylinux1_x86_64 bash -c \
  "ls -aslh /opt/python/cp36-cp36m"
0 lrwxrwxrwx 1 root root 28 May 26 19:25 /opt/python/cp36-cp36m -> /opt/_internal/cpython-3.6.8

Here is the same command running using python 3.6:

$ docker run --rm  \
  quay.io/pypa/manylinux1_x86_64 \
  /opt/python/cp36-cp36m/bin/python  -c \
  "from pip._internal.pep425tags import get_supported; \
   print('\n'.join('-'.join(x) for x in get_supported()))"

cp36-cp36m-manylinux1_x86_64
cp36-cp36m-linux_x86_64
cp36-abi3-manylinux1_x86_64
cp36-abi3-linux_x86_64
cp36-none-manylinux1_x86_64
cp36-none-linux_x86_64
cp35-abi3-manylinux1_x86_64
cp35-abi3-linux_x86_64
cp34-abi3-manylinux1_x86_64
cp34-abi3-linux_x86_64
cp33-abi3-manylinux1_x86_64
cp33-abi3-linux_x86_64
cp32-abi3-manylinux1_x86_64
cp32-abi3-linux_x86_64
py3-none-manylinux1_x86_64
py3-none-linux_x86_64
cp36-none-any
cp3-none-any
py36-none-any
py3-none-any
py35-none-any
py34-none-any
py33-none-any
py32-none-any
py31-none-any
py30-none-any

Worth noting that while the manylinux1 wheel is evaluated as valid by CandidateEvaluator.evaluate_link():

[...]
Found link https://files.pythonhosted.org/packages/45/c4/e69313ade2a3e992e7178744b0e56bdd8f23e79e15066a68cf490504beed/cmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl#sha256=fb60931c20bb8653d5c9d0ccb0ad0028804ece1a0797cb49222ee0358c8250c4 (from https://pypi.org/simple/cmake/), version: 3.13.3
[...]

the sdist for the newer version of the package ends up being installed.

@jcfr
Copy link
Contributor Author

jcfr commented May 27, 2019

Arff ... it looks like passing this option:

 --prefer-binary             Prefer older binary packages over newer source packages.

avoids the issue.

@cjerdonek
Copy link
Member

Okay, thanks. In the "Detailed Output" section of your original report, it says--

Skipping link https://files.pythonhosted.org/.../cmake-3.13.3-cp36-cp36m-manylinux1_i686.whl#...; it is not compatible with this Python

But with your second invocation you were getting different output (that was compatible)?

It would be good to update the detailed output in the original report if that was for a different version.

@cjerdonek
Copy link
Member

Okay, so that does that mean there isn't actually an issue anymore? Is there something that could have helped here?

@jcfr
Copy link
Contributor Author

jcfr commented May 27, 2019

Indeed, while the 686 wheel is skipped, the one x68_64 was not. I just updated the regex use to filter the output to make this obvious in the detailed output.

Okay, so that does that mean there isn't actually an issue anymore?

Indeed, passing --prefer-binary addresses the problem.

Is there something that could have helped here?

With the transition to manylinux2010, I anticipate build relying on binary wheels will start exerting a similar behavior (as expected), if such condition is detected I wonder if a warning could be reported.

Alternatively, I wonder if --prefer-binary should be enabled by default when there is an older manylinux1 binary wheel available. Along with displaying a message suggestion to use a newer platform.

This would streamline the user experience while providing a path forward.

@cjerdonek
Copy link
Member

Okay, glad it got sorted out.

Do you think you could open a new issue with your suggestions if you think there are some tweaks worth considering (e.g. warnings, changes in defaults, etc)?

@jcfr
Copy link
Contributor Author

jcfr commented May 27, 2019

Thanks again for the help, I created an issue with possible approaches and suggestion. Now closing this report.

@jcfr jcfr closed this as completed May 27, 2019
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 26, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation type: support User Support
Projects
None yet
Development

No branches or pull requests

2 participants