Discussion: should the default recipe set for python3 unconditionally include libffi to build ctypes? What about sqlite3 and other core modules?
See original GitHub issueI understand that not including libffi and ctypes brings down file size, but given it’s such a basic component of so many other libs and recipes (which often use it to interface with native code), I wonder if maybe it should be made part of the built-in default recipe set and always included?
Because this error isn’t super intuitive for beginners, and not something one would expect for a built-in module:
[INFO]: Building setuptools for armeabi-v7a
[INFO]: setuptools apparently isn't already in site-packages
[INFO]: Installing setuptools into site-packages
[INFO]: -> directory context /root/.local/share/python-for-android/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools
[DEBUG]: -> running python setup.py install -O2 --root=/root/.local/share/python-for-android/build/python-installs/unnamed_dist_1 --install-lib=.
[DEBUG]: Traceback (most recent call last):
[DEBUG]: File "setup.py", line 11, in <module>
[DEBUG]: import setuptools
[DEBUG]: File "/root/.local/share/python-for-android/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/__init__.py", line 14, in <module>
[DEBUG]: from setuptools.dist import Distribution, Feature
[DEBUG]: File "/root/.local/share/python-for-android/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/dist.py", line 25, in <module>
[DEBUG]: from setuptools import windows_support
[DEBUG]: File "/root/.local/share/python-for-android/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/windows_support.py", line 2, in <module>
[DEBUG]: import ctypes
[DEBUG]: File "/root/.local/share/python-for-android/build/other_builds/hostpython3/desktop/hostpython3/Lib/ctypes/__init__.py", line 7, in <module>
[DEBUG]: from _ctypes import Union, Structure, Array
[DEBUG]: ModuleNotFoundError: No module named '_ctypes'
Edit: cffi -> libffi
Issue Analytics
- State:
- Created 5 years ago
- Comments:11 (3 by maintainers)
Top Results From Across the Web
Failed to build these modules: _ctypes - when building Python ...
I'm trying to build Python 3.7.4 (as a non-root user on an older ... or to have installed, for the building of the...
Read more >Changelog — Python 3.11.1 documentation
gh-98790: Assumes that a missing DLLs directory means that standard extension modules are in the executable's directory. gh-98745: Update py.exe launcher to ...
Read more >Python-2.7.5/Misc/NEWS - toolchain/python - Git at Google
Issue #17857: Prevent build failures with pre-3.5.0 versions of sqlite3, ... Issue #17192: Update the ctypes module's libffi to v3.0.13. This.
Read more >Python 2.7 有什么新变化-BeJSON.com
This means Python now supports three different modules for parsing ... can contain sub-parsers to define subcommands that have different sets of switches, ......
Read more >Release 0.21.3 unknown - Pyodide
Our goal is to run some Python code in another thread, this other thread will not have access to the main thread objects....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yeah, I really think libffi, openssl, and sqlite3 should be included in the build. If space is an issue, someone should make a “tinypython” recipe to remove it.
Another point: if we move away from
--no-deps
inbuild.py
, move to running the project’ssetup.py
per default, and picking up pip recipes that match recipes automatically, then this is also a problem because a regular application would have none of the standard stuff as dependencies (since on desktop/all other platforms, it’s expected to be “just there”). So this steers us towards another weird long-term rift with IMHO no large need, when what I feel like we really should be doing is get closer to the desktop experience and a standardsetup.py
-powered process with standard pip dependency resolution, at least regarding p4a’s default behavior