Skip to content
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

How about updating setuptools, wheel, pip and installing setuptools-scm from git? #365

Closed
KOLANICH opened this issue Jan 19, 2019 · 5 comments · Fixed by #647
Closed

How about updating setuptools, wheel, pip and installing setuptools-scm from git? #365

KOLANICH opened this issue Jan 19, 2019 · 5 comments · Fixed by #647
Labels
Request Request for image modification or feature

Comments

@KOLANICH
Copy link

KOLANICH commented Jan 19, 2019

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?

@tao12345666333
Copy link
Contributor

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.

@wglambert wglambert added the Request Request for image modification or feature label Jan 21, 2019
@tianon
Copy link
Member

tianon commented Jan 21, 2019

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).

@riconnon
Copy link

Also related:
#511

I think the comment by @tianon would be a good approach, pinning the versions of the core packages for the duration of a Python release series.

@tianon
Copy link
Member

tianon commented Sep 7, 2021

The recent breaking changes in setuptools make this a bit more urgent IMO. 😞

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 pip and setuptools no problem in https://github.com/python/cpython/blob/3.10/Lib/ensurepip/__init__.py, but I cannot seem to figure out how wheel relates to these two.

Is it only included by default because it's a useful CLI tool for dealing with wheel files, and not because either of these two modules use it directly? 😩

@vikahl
Copy link
Contributor

vikahl commented Jan 26, 2022

Is it only included by default because it's a useful CLI tool for dealing with wheel files, and not because either of these two modules use it directly?

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 get-pip.py's behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Request for image modification or feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants