Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Set
PYTHONHOME
to work around relocation issue with uWSGI (#25)
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.
- Loading branch information