packaging
packaging copied to clipboard
64-bit Python running in 32-bit mode isn't able to install any of aarch64 and armv7l wheels
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
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.
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
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
.
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).
Thanks, didn't know about _have_compatible_abi
before, I'll look into it.
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.