GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||
GeezerVison is showing github.com — gh-116622: Android sysconfig updates by mhsmith · Pull Request #118352 · python/cpython Conversation
|
|
@encukou: Thanks for your help on my Android PRs in the last few days. Could I trouble you to review this one as well? It's pretty small, and it's the final one that needs to get merged before the feature freeze on May 7. |
All reactions
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
| "x86_64": "x86_64", | ||
| "i686": "x86", | ||
| "aarch64": "arm64_v8a", | ||
| "armv7l": "armeabi_v7a", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this is in the PEP (sorry I didn't catch it) but let me ask -- more to bring this to your attention than anything else:
Is there a specific reason to use Android arch names, rather than ones from configure?
For reference: Fedora used their own arch names, and spent several years migrating to the configure ones when wheels became more universal.
Android wheels will probably always be separate, but it seems they might be compared to other Linux-y wheels more often than other Android apps. Also, maintaining this dict in CPython might not be worth it.
If CPython-style arch names would be better, this is the time to change them.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are using autoconf-style architecture names everywhere else, including in extension module filenames (see test_android_ext_suffix in test_sysconfig.py). This PR really only affects the platform tag in wheel filenames.
The main reason to use this format is for consistency with the existing Chaquopy wheel repository, which contains over a thousand wheels for Python 3.8-3.12. Having two formats in use would complicate package installers such as pip (which we intend to contribute Android and iOS support for in the near future), and higher-level app building tools such as Briefcase.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are using autoconf-style architecture names everywhere else
Right, and this inconsistency is somewhat jarring.
If you'd be interested in setting up aliases in the Chaquopy repository, or adding aliases to packaging, let me know & I can help.
But, no reason for that to hold this PR back.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, this line of code does not work on 32-bit ARM Python 3.13 when it is running on an Android device that has a 32-bit ARM /system folder but a 64-bit ARM kernel.
On 32-bit ARM Python 3.13 when it is running on an Android device that has a 32-bit ARM /system folder but a 64-bit ARM kernel, this command (and any other pip command):
pip install packaging
unfortunately results in this error:
ERROR: Exception:
Traceback (most recent call last):
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_internal/cli/base_command.py", line 107, in _run_wrapper
status = _inner_run()
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_internal/cli/base_command.py", line 98, in _inner_run
return self.run(options, args)
~~~~~~~~^^^^^^^^^^^^^^^
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_internal/cli/req_command.py", line 96, in wrapper
return func(self, options, args)
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_internal/commands/install.py", line 391, in run
resolver = self.make_resolver(
preparer=preparer,
...<8 lines>...
py_version_info=options.python_version,
)
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_internal/cli/req_command.py", line 256, in make_resolver
return pip._internal.resolution.resolvelib.resolver.Resolver(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
preparer=preparer,
^^^^^^^^^^^^^^^^^^
...<9 lines>...
py_version_info=py_version_info,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_internal/resolution/resolvelib/resolver.py", line 61, in __init__
self.factory = Factory(
~~~~~~~^
finder=finder,
^^^^^^^^^^^^^^
...<7 lines>...
py_version_info=py_version_info,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 118, in __init__
self._supported_tags_cache = get_supported()
~~~~~~~~~~~~~^^
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_internal/utils/compatibility_tags.py", line 178, in get_supported
supported.extend(
~~~~~~~~~~~~~~~~^
cpython_tags(
^^^^^^^^^^^^^
...<3 lines>...
)
^
)
^
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_vendor/packaging/tags.py", line 229, in cpython_tags
platforms = list(platforms or platform_tags())
File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/pip/_vendor/packaging/tags.py", line 558, in android_platforms
abi = sysconfig.get_platform().split("-")[-1]
~~~~~~~~~~~~~~~~~~~~~~^^
File "/data/data/com.termux/files/usr/lib/python3.13/sysconfig/__init__.py", line 647, in get_platform
machine = {
~
...<3 lines>...
"armv7l": "armeabi_v7a",
~~~~~~~~~~~~~~~~~~~~~~~~
}[machine]
~^^^^^^^^^
KeyError: 'armv8l'
I have opened an issue here to catalog this:
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
|
Hah, it was the next thing on my list when you wrote that! Looks good, tell me to merge & I will :) |
All reactions
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Reviewers
+1 more reviewer
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assignedLabels
Projects
Milestone
No milestoneDevelopment
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
3 participants
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.