-
Notifications
You must be signed in to change notification settings - Fork 694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect stdlib path for relocated Python installs, resulting in ModuleNotFoundError: No module named 'encodings'
#2525
Comments
edmorley
added a commit
to heroku/buildpacks-python
that referenced
this issue
Apr 11, 2023
Our Python runtime is relocated (installed into a different location to which is was originally compiled) which Python itself handles well, since it recalculates its actual location at startup: https://docs.python.org/3.11/library/sys_path_init.html However, the uWSGI package uses the wrong `sysconfig` APIs so tries to reference the old compile location, unless we override that by setting `PYTHONHOME`: unbit/uwsgi#2525 This is a standard Python env var, and setting it is pretty harmless (now that the stack images no longer contain Python 2, so we don't have the dual install issue), so even though this is a uWSGI bug, it makes sense for us to work around it for now. (The classic Python buildpack also sets this env var, albeit that's primarily due to build and run time having different paths, and Python resolving symlinks unless `PYTHONHOME` is set.) See also: https://docs.python.org/3.11/using/cmdline.html#envvar-PYTHONHOME If this issue is ever fixed in uWSGI, we can always reconsider whether we need to set this env var - however, the issue will still exist in older uWSGI releases, plus there may be other packages similarly affected. No test has been added, since: - uWSGI doesn't ship wheels, and compiling it is slow in CI - I've tested the change works locally - `PYTHONHOME` is a built-in Python concept, so not something that really needs a uWSGI-specific test. The cache hasn't been force-invalidated (which would normally be required any time the env vars set by the buildpack change), since it's already due to be invalidated in the next buildpack release, due to the change in setuptools/wheel versions in #24). Fixes #18. GUS-W-12703344.
edmorley
added a commit
to heroku/buildpacks-python
that referenced
this issue
Apr 11, 2023
Our Python runtime is relocated (installed into a different location to which is was originally compiled) which Python itself handles well, since it recalculates its actual location at startup: https://docs.python.org/3.11/library/sys_path_init.html However, the uWSGI package uses the wrong `sysconfig` APIs so tries to reference the old compile location, unless we override that by setting `PYTHONHOME`: unbit/uwsgi#2525 This is a standard Python env var, and setting it is pretty harmless (now that the stack images no longer contain Python 2, so we don't have the dual install issue), so even though this is a uWSGI bug, it makes sense for us to work around it for now. (The classic Python buildpack also sets this env var, albeit that's primarily due to build and run time having different paths, and Python resolving symlinks unless `PYTHONHOME` is set.) See also: https://docs.python.org/3.11/using/cmdline.html#envvar-PYTHONHOME If this issue is ever fixed in uWSGI, we can always reconsider whether we need to set this env var - however, the issue will still exist in older uWSGI releases, plus there may be other packages similarly affected. No test has been added, since: - uWSGI doesn't ship wheels, and compiling it is slow in CI - I've tested the change works locally - `PYTHONHOME` is a built-in Python concept, so not something that really needs a uWSGI-specific test. The cache hasn't been force-invalidated (which would normally be required any time the env vars set by the buildpack change), since it's already due to be invalidated in the next buildpack release, due to the change in setuptools/wheel versions in #24). Fixes #18. GUS-W-12703344.
Something else I've just discovered - this issue only affects uWSGI when it was installed into the user site-packages using using |
This was referenced Aug 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
uWSGI calculates the Python stdlib location incorrectly for Python installs that have been relocated, resulting in the server failing to start due to:
This appears to be because uWSGI is using the wrong
sysconfig
APIs to calculate Python home and the location of the standard library - and so uWSGI attempts to use them from the hardcoded compilation time paths, rather than the new Python location reported bysys.prefix
and othersysconfig
APIs.Steps to reproduce
mkdir uwsgi-testcase && cd $_
touch Dockerfile app.py
Dockerfile
andapp.py
to have the contents listed belowdocker build -t uwsgi-test .
docker run --rm -it uwsgi-test
docker run --rm -it uwsgi-test python -c 'import pprint, sys, sysconfig; print("sys.prefix:", sys.prefix); print("sys.path:", pprint.pformat(sys.path)); print("sysconfig.get_paths():", pprint.pformat(sysconfig.get_paths()))'
Expected
Python path configuration
section of the uWSGI server output lists the correct locations for the Python installation (paths under/foo/python
) that match whatsys.prefix
andsysconfig.get_paths()
report.Actual
Python path configuration
section of the uWSGI server output lists the wrong locations for the Python installation (paths under/app/.heroku/python
) that don't match whatsys.prefix
andsysconfig.get_paths()
report.PYTHONHOME
env var has to be set to override uWSGI's incorrect location. For example, by runningdocker run --rm -it --env PYTHONHOME='/foo/python' uwsgi-test
.In comparison, Python's stdlib has the correct paths:
Versions
Notes
sys.prefix
andsysconfig.get_paths()
report the correct locations. How Python determines the Python location is documented here.sysconfig
(egLIBS
andSYSLIBS
) which are hardcoded by Python at time of build, and so don't change when the Python installation is relocated. To resolve this issue, it seems these usages should be switched to one of the othersysconfig
APIs instead. See:uwsgi/plugins/python/uwsgiplugin.py
Line 40 in 73efb01
The text was updated successfully, but these errors were encountered: