-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Switch from get-pip to ensurepip #951
Comments
Oh, very interesting proposal -- I can't remember why we explicitly disabled usage of From what I can tell, in 3.12+ it effectively just installs itself (no downloading or other modules), so we could even stop scraping Does it maybe install to a different path than the explicit/ |
There are two ways we could use
When I filed this issue I was thinking of (1). Searching issues/PRs for ensurepip prior art, I found:
So it appears that:
I think things have changed a fair bit since then:
As such, using |
Nice, thank you for the detailed digging! This is really helpful. ❤️ Looking at https://docs.python.org/3/library/ensurepip.html, |
I have a WIP of this locally, but will wait until #954 merged before continuing with it, to avoid conflicts. |
Since: * All versions of Python that are actively built by this repo now include the `ensurepip` module. * The policy of these images is now to use the same pip version as the one bundled with `ensurepip` (rather than always upgrading as pip releases occur) to avoid breaking changes, and for parity with the `venv` module. * As such, we might as well actually use `ensurepip` to install pip (since it installs the exact pip version we want) rather than manually doing the same using `get-pip.py`. Now that the pip/setuptools versions track (or mostly track, in the case of setuptools) the ensurepip versions, the concerns over frequent invalidation of the Python layer no longer apply, and so the pip/setuptools install can now be part of the Python layer, reducing layer count by one. This change is a no-op in terms of pip/setuptools/wheel versions, since the pip versions being used already exactly matched the `ensurepip` version of pip. Closes docker-library#951.
I've opened #955 for this, and chose approach (2) from #951 (comment). There's no rush to look at that PR - I think it makes sense to wait until #954 has been released for a bit to reduce the chance of further churn :-) |
Since: * All versions of Python that are actively built by this repo now include the `ensurepip` module. * The policy of these images is now to use the same pip version as the one bundled with `ensurepip` (rather than always upgrading as pip releases occur) to avoid breaking changes, and for parity with the `venv` module. * As such, we might as well actually use `ensurepip` to install pip (since it installs the exact pip version we want) rather than manually doing the same using `get-pip.py`. Now that the pip/setuptools versions track (or mostly track, in the case of setuptools) the ensurepip versions, the concerns over frequent invalidation of the Python layer no longer apply, and so the pip/setuptools install can now be part of the Python layer, reducing layer count by one. This change is a no-op in terms of pip/setuptools/wheel versions, since the pip versions being used already exactly matched the `ensurepip` version of pip. Closes docker-library#951.
Since: * All versions of Python that are actively built by this repo now include the `ensurepip` module. * The policy of these images is now to use the same pip version as the one bundled with `ensurepip` (rather than always upgrading as pip releases occur) to avoid breaking changes, and for parity with the `venv` module. * As such, we might as well actually use `ensurepip` to install pip (since it installs the exact pip version we want) rather than manually doing the same using `get-pip.py`. Now that the pip/setuptools versions track (or mostly track, in the case of setuptools) the ensurepip versions, the concerns over frequent invalidation of the Python layer no longer apply, and so the pip/setuptools install can now be part of the Python layer, reducing layer count by one. This change is a no-op in terms of pip/setuptools/wheel versions, since the pip versions being used already exactly matched the `ensurepip` version of pip. Closes docker-library#951.
The images in this repo currently use https://github.com/pypa/get-pip to bootstrap pip, however, all versions of Python supported here now include the
ensurepip
module (which was added in Python 3.4), which could be used instead (along with a suitablepip install -U
command to upgrade to the chosen pinned pip etc):https://docs.python.org/3/library/ensurepip.html
Switching to
ensurepip
would remove an external dependency and the script version bumping that comes with it (eg 1980d7b x8 for each upstream get-pip change).Would you be open to a PR that made that switch?
The text was updated successfully, but these errors were encountered: