Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
pip doesn't work from statically linked executables #6543
In the bowels of pip, the
This is arguably a bug in CPython's
I think pip should handle failure to import the
How to Reproduce
With a statically linked Python executable that doesn't have a
The zstd compressed tarball at https://github.com/indygreg/python-build-standalone/releases/download/20190505/cpython-3.7.3-linux64-musl-20190526T0219.tar.zst contains such an executable under
The problem with CPython specifically:
setuptools is also affected. I figure I'll wait for someone from the PyPA to comment on matters before I file an issue / submit a PR to setuptools.
Note - your actual issue here is in
But assuming you do want to treat the broader issue as worth addressing:
I strongly believe that this is a ctypes bug - there's no way that it's reasonable to expect every import of a stdlib module to be checked for errors in every project. And it's not as if ctypes is documented as an optional stdlib module (at least not that I could see). Having said that, I see the reasoning that we have to live with the reality, and therefore we might have to deal with this. But many of our ctypes usages are in vendored libraries (colorama, urllib3) so you'll need to raise issues against those projects as well. And I'd still argue for fixing issues on a case by case basis, prompted by real world problems, rather than just making a blanket rule that we always have to protect ctypes usage (it's not like we make provision for systems where threading isn't available, for example).
I would want to watch the Python bug report closely, though - if the CPython core devs don't accept that it's a bug for "import ctypes" to fail, then at a minimum the CPython docs should make that clear - there's nothing in the docs at the moment to suggest that it's any more acceptable for "import ctypes" to fail than (say) "import subprocess".
I agree that this is a ctypes bug. I think it is best for ctypes import to gracefully handle the OSError and continue with import.
Then the question becomes what should consumers of ctypes do - if anything - to work around the import time failure in existing Python releases. I highly doubt many people out there have built a non-dynamic Python binary. I think it is a reasonable stance to tell people they need a minimum version of Python - perhaps 3.7.4 - to run a fully static binary.
But there's still the run-time issue of
In any case, I've worked around this issue in python-build-standalone by patching cpython, setuptools, and pip.