packaging icon indicating copy to clipboard operation
packaging copied to clipboard

64-bit Python running in 32-bit mode isn't able to install any of aarch64 and armv7l wheels

Open messense opened this issue 3 years ago • 6 comments

On a 64-bit Raspberry Pi, sysconfig.get_platform() returns linux_armv8l instead of linux_aarch64 while sys.maxsize is over 32-bit range

root@raspberrypi:~# linux32 python3 -c 'import sysconfig; print(sysconfig.get_platform())'
linux-armv8l
root@raspberrypi:~# linux32 python3 -m 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 21.3.1 from /usr/local/lib/python3.8/dist-packages/pip (python 3.8)
sys.version: 3.8.2 (default, Mar 13 2020, 10:14:16)
[GCC 9.2.1 20200306]
sys.executable: /usr/bin/python3
sys.getdefaultencoding: utf-8
sys.getfilesystemencoding: utf-8
locale.getpreferredencoding: UTF-8
sys.platform: linux
sys.implementation:
  name: cpython
'cert' config value: Not specified
REQUESTS_CA_BUNDLE: None
CURL_CA_BUNDLE: None
pip._vendor.certifi.where(): /usr/local/lib/python3.8/dist-packages/pip/_vendor/certifi/cacert.pem
pip._vendor.DEBUNDLED: False
vendored library versions:
  CacheControl==0.12.6
  colorama==0.4.4
  distlib==0.3.3
  distro==1.6.0
  html5lib==1.1
  msgpack==1.0.2 (Unable to locate actual module version, using vendor.txt specified version)
  packaging==21.0
  pep517==0.12.0
  platformdirs==2.4.0
  progress==1.6
  pyparsing==2.4.7
  requests==2.26.0
  certifi==2021.05.30
  chardet==4.0.0
  idna==3.2
  urllib3==1.26.7
  resolvelib==0.8.0
  setuptools==44.0.0 (Unable to locate actual module version, using vendor.txt specified version)
  six==1.16.0
  tenacity==8.0.1 (Unable to locate actual module version, using vendor.txt specified version)
  tomli==1.0.3
  webencodings==0.5.1 (Unable to locate actual module version, using vendor.txt specified version)
Compatible tags: 30
  cp38-cp38-linux_armv8l
  cp38-abi3-linux_armv8l
  cp38-none-linux_armv8l
  cp37-abi3-linux_armv8l
  cp36-abi3-linux_armv8l
  cp35-abi3-linux_armv8l
  cp34-abi3-linux_armv8l
  cp33-abi3-linux_armv8l
  cp32-abi3-linux_armv8l
  py38-none-linux_armv8l
  py3-none-linux_armv8l
  py37-none-linux_armv8l
  py36-none-linux_armv8l
  py35-none-linux_armv8l
  py34-none-linux_armv8l
  py33-none-linux_armv8l
  py32-none-linux_armv8l
  py31-none-linux_armv8l
  py30-none-linux_armv8l
  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
root@raspberrypi:~# linux32 python3
Python 3.8.2 (default, Mar 13 2020, 10:14:16)
[GCC 9.2.1 20200306] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxsize <= 2 ** 32
False

This makes tests on Alpine Linux's CI fails sometimes, for example https://gitlab.alpinelinux.org/omni/aports/-/jobs/514000 , looks like they're running armv7 and armhf gitlab runners on 64-bit ARM machines in 32 bit mode.

Originally posted in https://github.com/pypa/packaging/pull/234#discussion_r737238107

messense avatar Oct 27 '21 08:10 messense

sysconfig.get_platform()

This is unrelated to this package? sysconfig is a Python standard library module -- https://docs.python.org/3/library/sysconfig.html -- which is generated when it is compiled.

pradyunsg avatar Oct 27 '21 09:10 pradyunsg

sysconfig.get_platform() is a little more complicated than returning a constant string I think? https://github.com/python/cpython/blob/36971fd1f490664fb62b1fab869c5637669f0967/Lib/sysconfig.py#L670-L748

messense avatar Oct 27 '21 09:10 messense

https://github.com/pypa/packaging/blob/20cd09e00917adbc4afeaa753be831a6bc2740f7/packaging/tags.py#L417-L427

What I expect is that this also consider linux_armv8l as linux_armv7l.

messense avatar Oct 27 '21 09:10 messense

No, I believe linux_armv8l should be passed into _manylinux.platform_tags() and handled in _have_compatible_abi. This function should likely also be expanded for forward compatibility against (say) armv9, but I'm not sure how it can be handled best. Especially since they'd hit the Y2K problem in the version after that (ARM v10).

uranusjr avatar Oct 27 '21 13:10 uranusjr

Thanks, didn't know about _have_compatible_abi before, I'll look into it.

messense avatar Oct 27 '21 13:10 messense

Running 64-bit python under a linux32 is probably somewhat of an edge case. It's not taken into account for x86_64/i686 without reports of issues in that case. I'm not saying nothing should be done, I'm just saying it's probably much less of an issue than armv8l not being able to install armv7l wheels. I'll open a PR for armv8l ability to install manylinux/musllinux armv7l wheels.

mayeut avatar Apr 23 '23 11:04 mayeut