-
Notifications
You must be signed in to change notification settings - Fork 1.1k
How about updating setuptools, wheel, pip and installing setuptools-scm from git? #365
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
Comments
I think the official image is a foundation core, and it should provide a stable version of the tool, users can upgrade if necessary. There is no need to do this in the official image. |
See also docker-library/ruby#255, where we're actively taking Ruby in the opposite direction of this proposal (ie, leaving the versions of Bundler and RubyGems alone and simply providing whatever the particular Ruby release comes with). IMO it'd be interesting/useful to have a similar conversation with the Pip (and/or Python) maintainers and see whether they feel like it would be better for us to continue bumping Pip to the latest release or whether we should instead level that off and eventually simply provide whatever version of Pip that Python comes with by default (as we're now doing with Ruby). |
The recent breaking changes in In looking into the details of how to implement this, my plan was to pin everything to whatever's the latest minor release of each today, with the plan in the future to be pinning to the minor release track that's included with the associated Python release (for example, if Python 3.11 contains PIP 22.x, we'd pin to that same 22.x for the duration of Python 3.11). I can find the appropriate versions for both Is it only included by default because it's a useful CLI tool for dealing with |
I am nowhere near an expert on this, but I got curious and tried to dig Pip builds wheels for dependencies by default, if the wheel module is installed. I have however not found any link between versions for Pip/Setuptools and Wheels, nor any documentation on compatibility. I assume that wheel use semantic versioning so pinning to <1 would be one way, another would be to leave it as is (and not pin) since that would mimic |
Rationale: the stuff mentioned has a very long release cycle. It takes a while before features and fixes available in git are landed into release. I have been using the bleeding edge stuff from git in CI (installed manually upon
python:latest
) for a long time and experienced no problems with it, only benefits. So I think it may make sense to include this stuff into the images to ship it by default.What does the community think about it?
The text was updated successfully, but these errors were encountered: