Set PYTHONHOME to work around relocation issue with uWSGI#25
Merged
Conversation
edmorley
added
bug
edmorley
force-pushed
the
set-pythonhome
branch
from
ed4b000 to
272df2c
Compare
Malax
approved these changes
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
force-pushed
the
set-pythonhome
branch
from
272df2c to
bd6ccbb
Compare
Merged
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Our Python runtime is relocated (installed into a different location to which it 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 (a slightly older web server, but still has 50,000 downloads a day from PyPI) uses the wrong
sysconfigAPIs so tries to reference the old compile location, unless we override that by settingPYTHONHOME: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
PYTHONHOMEis 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:
PYTHONHOMEis a built-in Python concept, so there is less need for a uWSGI-specific test.The layer 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.