-
Notifications
You must be signed in to change notification settings - Fork 3
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
Error running locally built image with pack: Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding #18
Comments
@david-caro Thank you for the great bug report + testcase, that helped a lot with my being able to reproduce. This looks like a potential bug in uWSGI (or at least a limitation of it), since it's not honouring Python's detection of stdlib location, and instead is using the original build time location of Python, before it was relocated. For example, if you run I'm planning on reporting this upstream to uWSGI, as well as having the Python CNB set |
I've reported this upstream to the uWSGI project here: |
This is more of a workaround than a fix, but I'm curious if using https://pypi.org/project/pyuwsgi/ resolves the issue. |
I just noticed the GCP Python CNB sets |
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.
Not sure what I'm doing wrong, it might be a dummy thing, but when trying to run a locally built image (with pack) using the heroku/builder:22, I get the error:
The build process works well:
I can run it though if I set both
PYTHONHOME
andLD_LIBRARY_PATH
to point to the python layer dirs:The code I'm running is https://github.com/david-caro/wm-lol (simple python app uwsgi+flask), but tested with the sample python app too with the same error
Note: moved from heroku/heroku-buildpack-python#1427
The text was updated successfully, but these errors were encountered: