Update setuptools to 67.6.1 and wheel to 0.40.0 #24
Conversation
This file contains 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
edmorley
force-pushed
the
update-setuptools-wheel
branch
from
ae508d6
to
b81ca7f
Compare
- Setuptools has been updated from 67.5.0 to 67.6.1. - Wheel has been updated from 0.38.4 to 0.40.0. Changes: https://setuptools.pypa.io/en/stable/history.html#v67-6-1 https://wheel.readthedocs.io/en/stable/news.html GUS-W-13011118. GUS-W-13011108.
edmorley
force-pushed
the
update-setuptools-wheel
branch
from
b81ca7f
to
bd1d417
Compare
Malax
approved these changes
Apr 11, 2023
edmorley
added a commit
that referenced
this pull request
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.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Changes:
https://setuptools.pypa.io/en/stable/history.html#v67-6-1
https://wheel.readthedocs.io/en/stable/news.html
GUS-W-13011118.
GUS-W-13011108.