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.

Sign up for GitHub

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

Jump to bottom

Pip fails to install in-house wheel on Mac OS 11 #335

Closed
otrejoso opened this issue Sep 22, 2020 · 6 comments
Closed

Pip fails to install in-house wheel on Mac OS 11 #335

otrejoso opened this issue Sep 22, 2020 · 6 comments
Labels
packaging.tags

Comments

@otrejoso
Copy link

We have an in-house wheel package that we maintain and were testing the wheel on Mac OS 11, when I tried to install my wheel I go the following error

ERROR: Could not find a version that satisfies the requirement pti==2.1.621 (from versions: 1.23.dev2180741298520)
ERROR: No matching distribution found for pti==2.1.621

Looking through the verbose output, I get:

skipping link: none of the wheel's tags match: py3-none-macosx_10_12_x86_64: http://artifactory.mydomain.com:8081/artifactory/api/pypi/pypi-virtual/pti/2.1.621/pti-2.1.621-py3-none-macosx_10_12_x86_64.whl#md5=7d443750397b13e09f54f15babb0327a (from http://artifactory.mydomain.com:8081/artifactory/api/pypi/pypi-virtual/simple/pti/)

pti-2.1.621-py3-none-macosx_10_12_x86_64.whl -> I always looked 10_12 as min os version, but reading through https://www.python.org/dev/peps/pep-0425/#id13, now that makes me think it is just the version of the mac os version thw wheel was built under which doesn't match what MacOS 11 is looking for

(venv3.7) mac-d5bdd:otrejooso localadmin$ pip debug --verbose
WARNING: This command is only meant for debugging. Do not use this with automation for parsing and getting these details, since the output and options of this command may change without notice.
pip version: pip 20.2.3 from /Users/localadmin/otrejooso/venv3.7/lib/python3.8/site-packages/pip (python 3.8)
sys.version: 3.8.2 (default, Jul 14 2020, 05:39:05)
[Clang 12.0.0 (clang-1200.0.26.2)]
sys.executable: /Users/localadmin/otrejooso/venv3.7/bin/python3
sys.getdefaultencoding: utf-8
sys.getfilesystemencoding: utf-8
locale.getpreferredencoding: UTF-8
sys.platform: darwin
sys.implementation:
  name: cpython
'cert' config value: Not specified
REQUESTS_CA_BUNDLE: None
CURL_CA_BUNDLE: None
pip._vendor.certifi.where(): /Users/localadmin/otrejooso/venv3.7/lib/python3.8/site-packages/pip/_vendor/certifi/cacert.pem
pip._vendor.DEBUNDLED: False
vendored library versions:
  appdirs==1.4.4
  CacheControl==0.12.6
  colorama==0.4.3
  contextlib2==0.6.0.post1 (Unable to locate actual module version, using vendor.txt specified version)
  distlib==0.3.1
  distro==1.5.0 (Unable to locate actual module version, using vendor.txt specified version)
  html5lib==1.1
  ipaddress==1.0.23
  msgpack==1.0.0 (Unable to locate actual module version, using vendor.txt specified version)
  packaging==20.4
  pep517==0.8.2
  progress==1.5
  pyparsing==2.4.7
  requests==2.24.0
  certifi==2020.06.20
  chardet==3.0.4
  idna==2.10
  urllib3==1.25.9
  resolvelib==0.4.0
  retrying==1.3.3 (Unable to locate actual module version, using vendor.txt specified version)
  setuptools==44.0.0 (Unable to locate actual module version, using vendor.txt specified version)
  six==1.15.0
  toml==0.10.1
  webencodings==0.5.1 (Unable to locate actual module version, using vendor.txt specified version)
Compatible tags: 106
  cp38-cp38-macosx_11_0_x86_64
  cp38-cp38-macosx_11_0_intel
  cp38-cp38-macosx_11_0_fat64
  cp38-cp38-macosx_11_0_fat32
  cp38-cp38-macosx_11_0_universal
  cp38-abi3-macosx_11_0_x86_64
  cp38-abi3-macosx_11_0_intel
  cp38-abi3-macosx_11_0_fat64
  cp38-abi3-macosx_11_0_fat32
  cp38-abi3-macosx_11_0_universal
  cp38-none-macosx_11_0_x86_64
  cp38-none-macosx_11_0_intel
  cp38-none-macosx_11_0_fat64
  cp38-none-macosx_11_0_fat32
  cp38-none-macosx_11_0_universal
  cp37-abi3-macosx_11_0_x86_64
  cp37-abi3-macosx_11_0_intel
  cp37-abi3-macosx_11_0_fat64
  cp37-abi3-macosx_11_0_fat32
  cp37-abi3-macosx_11_0_universal
  cp36-abi3-macosx_11_0_x86_64
  cp36-abi3-macosx_11_0_intel
  cp36-abi3-macosx_11_0_fat64
  cp36-abi3-macosx_11_0_fat32
  cp36-abi3-macosx_11_0_universal
  cp35-abi3-macosx_11_0_x86_64
  cp35-abi3-macosx_11_0_intel
  cp35-abi3-macosx_11_0_fat64
  cp35-abi3-macosx_11_0_fat32
  cp35-abi3-macosx_11_0_universal
  cp34-abi3-macosx_11_0_x86_64
  cp34-abi3-macosx_11_0_intel
  cp34-abi3-macosx_11_0_fat64
  cp34-abi3-macosx_11_0_fat32
  cp34-abi3-macosx_11_0_universal
  cp33-abi3-macosx_11_0_x86_64
  cp33-abi3-macosx_11_0_intel
  cp33-abi3-macosx_11_0_fat64
  cp33-abi3-macosx_11_0_fat32
  cp33-abi3-macosx_11_0_universal
  cp32-abi3-macosx_11_0_x86_64
  cp32-abi3-macosx_11_0_intel
  cp32-abi3-macosx_11_0_fat64
  cp32-abi3-macosx_11_0_fat32
  cp32-abi3-macosx_11_0_universal
  py38-none-macosx_11_0_x86_64
  py38-none-macosx_11_0_intel
  py38-none-macosx_11_0_fat64
  py38-none-macosx_11_0_fat32
  py38-none-macosx_11_0_universal
  py3-none-macosx_11_0_x86_64
  py3-none-macosx_11_0_intel
  py3-none-macosx_11_0_fat64
  py3-none-macosx_11_0_fat32
  py3-none-macosx_11_0_universal
  py37-none-macosx_11_0_x86_64
  py37-none-macosx_11_0_intel
  py37-none-macosx_11_0_fat64
  py37-none-macosx_11_0_fat32
  py37-none-macosx_11_0_universal
  py36-none-macosx_11_0_x86_64
  py36-none-macosx_11_0_intel
  py36-none-macosx_11_0_fat64
  py36-none-macosx_11_0_fat32
  py36-none-macosx_11_0_universal
  py35-none-macosx_11_0_x86_64
  py35-none-macosx_11_0_intel
  py35-none-macosx_11_0_fat64
  py35-none-macosx_11_0_fat32
  py35-none-macosx_11_0_universal
  py34-none-macosx_11_0_x86_64
  py34-none-macosx_11_0_intel
  py34-none-macosx_11_0_fat64
  py34-none-macosx_11_0_fat32
  py34-none-macosx_11_0_universal
  py33-none-macosx_11_0_x86_64
  py33-none-macosx_11_0_intel
  py33-none-macosx_11_0_fat64
  py33-none-macosx_11_0_fat32
  py33-none-macosx_11_0_universal
  py32-none-macosx_11_0_x86_64
  py32-none-macosx_11_0_intel
  py32-none-macosx_11_0_fat64
  py32-none-macosx_11_0_fat32
  py32-none-macosx_11_0_universal
  py31-none-macosx_11_0_x86_64
  py31-none-macosx_11_0_intel
  py31-none-macosx_11_0_fat64
  py31-none-macosx_11_0_fat32
  py31-none-macosx_11_0_universal
  py30-none-macosx_11_0_x86_64
  py30-none-macosx_11_0_intel
  py30-none-macosx_11_0_fat64
  py30-none-macosx_11_0_fat32
  py30-none-macosx_11_0_universal
  cp38-none-any
  py38-none-any
  py3-none-any
  py37-none-any
  py36-none-any
  py35-none-any
  py34-none-any
  py33-none-any
  py32-none-any
  py31-none-any
  py30-none-any

Does this mean that any wheel built on Mac 10.X.X will not work unless those wheel are built on 11? Or is this something be addressed in the coming release for pip?
@uranusjr
Copy link
Member

uranusjr commented Sep 22, 2020 •
edited
Loading

You thought correctly, 10.12 is meant to indicate the minimal version, but I think the tag logic uses something like semantic versioning. Since nobody knows what macOS 11 looks like before it actually happened, it was assumed to be backwards incompatible, and thus wheels built on 10.12 was assumed to be incompatible to 11.0.

We should transfer this issue to pypa/packaging @pradyunsg

@pradyunsg pradyunsg transferred this issue from pypa/pip Sep 22, 2020
@pradyunsg
Copy link
Member

/cc @brettcannon I guess?

@otrejoso
Copy link
Author

@uranusjr I think that seems that is the wrong approach to take, does it not? 🤔 . Basically having any pip package built on 10 will not work on future major version OS version seems to be the wrong approach.. it is just like building an app with minor version 10.12... Any future OS should run unless Apple says otherwhise. It is like when they drop 32... If a customer try to run a 32 app, the OS will complain that is not supported.
Anyways, hopefully this can be address 😞

@brettcannon
Copy link
Member

It's because this is for macOS 11 and we don't have support for that version yet. See #319 and https://discuss.python.org/t/apple-silicon-and-packaging/4516.

Closing as a duplicate of #318

@uranusjr
Copy link
Member

For completeness, the current implementation is most certainly not a wrong approach to take. Nobody knows whether macOS 11 would be compatible with 10.x before it came out (except maybe a very small group of people in Apple who don’t involve in Python packaging at all), and the only sensible way to do this is to assume it’s incompatible. If the new version ends up being compatible (as things turns out), we can just release a new pip version for everyone on the new version. If things were assumed to be compatible and but turns out not so, we would have no way to retrospectively prevent people from installing incompatible wheels on macOS 11. That would be a disaster for everybody.

@otrejoso
Copy link
Author

@uranusjr hmmm... Not sure if I agree 100% with that. Although, I understand what you are saying, then I would argue: If the concern is to avoid having people to install incompatible wheels on Mac OS 11, then why this is already sort of allowed to be done by just upgrading from 10 to 11. Basically, if I have a mac 10 with my pre existing pip packages already installed there, and I decided to upgrade to 11 beta, my pip packages will work continue to work. And I mentioned this because we already tried to do ths in an existing machine we have. We didn't stumble upon any problem until we decided to try in full clean mac 11 machine. Unless we just were lucky 🤔
I can see the case for different architectures, but for same architectectures, not sure if I am convinced. Unless there is something hidden in python I am not aware.

Anyways, I trust you guys 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
packaging.tags
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@brettcannon @uranusjr @pradyunsg @otrejoso