gh-95299: Stop installing setuptools as a part of ensurepip and venv by pradyunsg · Pull Request #101039 · python/cpython
labels
webknjaz added a commit to webknjaz/cpython that referenced this pull request
This is a refactoring change that aims to simplify ``ensurepip``. Before it, this module had legacy infrastructure that made an assumption that ``ensurepip`` would be provisioning more then just a single wheel. That assumption is no longer true since [[1]][[2]][[3]]. In this change, the improvement is done around removing unnecessary loops and supporting structures to change the assumptions to expect only the bundled or replacement ``pip`` wheel. [1]: python@ece20db [2]: python#101039 [2]: python#95299
webknjaz added a commit to webknjaz/cpython that referenced this pull request
This is a refactoring change that aims to simplify ``ensurepip``. Before it, this module had legacy infrastructure that made an assumption that ``ensurepip`` would be provisioning more then just a single wheel. That assumption is no longer true since [[1]][[2]][[3]]. In this change, the improvement is done around removing unnecessary loops and supporting structures to change the assumptions to expect only the bundled or replacement ``pip`` wheel. [1]: python@ece20db [2]: python#101039 [3]: python#95299
webknjaz added a commit to webknjaz/cpython that referenced this pull request
This is a refactoring change that aims to simplify ``ensurepip``. Before it, this module had legacy infrastructure that made an assumption that ``ensurepip`` would be provisioning more then just a single wheel. That assumption is no longer true since [[1]][[2]][[3]]. In this change, the improvement is done around removing unnecessary loops and supporting structures to change the assumptions to expect only the bundled or replacement ``pip`` wheel. [1]: python@ece20db [2]: python#101039 [3]: python#95299
webknjaz added a commit to webknjaz/cpython that referenced this pull request
This is a refactoring change that aims to simplify ``ensurepip``. Before it, this module had legacy infrastructure that made an assumption that ``ensurepip`` would be provisioning more then just a single wheel. That assumption is no longer true since [[1]][[2]][[3]]. In this change, the improvement is done around removing unnecessary loops and supporting structures to change the assumptions to expect only the bundled or replacement ``pip`` wheel. [1]: python@ece20db [2]: python#101039 [3]: python#95299
webknjaz added a commit to webknjaz/cpython that referenced this pull request
This is a refactoring change that aims to simplify ``ensurepip``. Before it, this module had legacy infrastructure that made an assumption that ``ensurepip`` would be provisioning more then just a single wheel. That assumption is no longer true since [[1]][[2]][[3]]. In this change, the improvement is done around removing unnecessary loops and supporting structures to change the assumptions to expect only the bundled or replacement ``pip`` wheel. [1]: python@ece20db [2]: python#101039 [3]: python#95299
edmorley added a commit to edmorley/get-pip that referenced this pull request
Currently `get-pip.py` installs not only pip, but also setuptools and wheel by default, unless the `--no-setuptools` / `--no-wheel` (or `PIP_NO_SETUPTOOLS` / `PIP_NO_WHEEL` env vars) are used. This has historically been necessary, however, modern versions of pip will now fallback to `pyproject.toml` (PEP 517: [1]) based builds (which will default to a setuptools backend, and thus automatically install setuptools and wheel in the isolated build environment) if either setuptools is not installed (as of pip 22.1: [2]), or if wheel is not installed (as of pip 23.1: [3]). In addition, as of Python 3.12, the stdlib's `ensurepip` and `venv` modules no longer install setuptools, and only install pip ([4]). As such, it is now time for `get-pip.py` to stop installing setuptools and wheel by default on Python 3.12+, in order to: - Act as another small step towards `pyproject.toml` / PEP 517 based builds eventually becoming the pip default. - Improve parity with the behaviour of `ensurepip` / `venv` on Python 3.12+. - Allow `get-pip.py` to focus on its primary responsibility: bootstrapping Pip. Closes pypa#200. [1]: https://peps.python.org/pep-0517/ [2]: pypa/pip#10717 [3]: pypa/pip#11871 [4]: python/cpython#101039
edmorley added a commit to edmorley/get-pip that referenced this pull request
Currently `get-pip.py` installs not only pip, but also setuptools and wheel by default, unless the `--no-setuptools` / `--no-wheel` (or `PIP_NO_SETUPTOOLS` / `PIP_NO_WHEEL` env vars) are used. This has historically been necessary, however, modern versions of pip will now fallback to `pyproject.toml` (PEP 517: [1]) based builds (which will default to a setuptools backend, and thus automatically install setuptools and wheel in the isolated build environment) if either setuptools is not installed (as of pip 22.1: [2]), or if wheel is not installed (as of pip 23.1: [3]). In addition, as of Python 3.12, the stdlib's `ensurepip` and `venv` modules no longer install setuptools, and only install pip ([4]). As such, it is now time for `get-pip.py` to stop installing setuptools and wheel by default on Python 3.12+, in order to: - Act as another small step towards `pyproject.toml` / PEP 517 based builds eventually becoming the pip default. - Improve parity with the behaviour of `ensurepip` / `venv` on Python 3.12+. - Allow `get-pip.py` to focus on its primary responsibility: bootstrapping Pip. Closes pypa#200. [1]: https://peps.python.org/pep-0517/ [2]: pypa/pip#10717 [3]: pypa/pip#11871 [4]: python/cpython#101039
edmorley added a commit to edmorley/get-pip that referenced this pull request
Currently `get-pip.py` installs not only pip, but also setuptools and wheel by default, unless the `--no-setuptools` / `--no-wheel` (or `PIP_NO_SETUPTOOLS` / `PIP_NO_WHEEL` env vars) are used. This has historically been necessary, however, modern versions of pip will now fallback to `pyproject.toml` (PEP 517: [1]) based builds (which will default to a setuptools backend, and thus automatically install setuptools and wheel in the isolated build environment) if either setuptools is not installed (as of pip 22.1: [2]), or if wheel is not installed (as of pip 23.1: [3]). In addition, as of Python 3.12, the stdlib's `ensurepip` and `venv` modules no longer install setuptools, and only install pip ([4]). As such, it is now time for `get-pip.py` to stop installing setuptools and wheel by default on Python 3.12+, in order to: - Act as another small step towards `pyproject.toml` / PEP 517 based builds eventually becoming the pip default. - Improve parity with the behaviour of `ensurepip` / `venv` on Python 3.12+. - Allow `get-pip.py` to focus on its primary responsibility: bootstrapping Pip. Closes pypa#200. [1]: https://peps.python.org/pep-0517/ [2]: pypa/pip#10717 [3]: pypa/pip#11871 [4]: python/cpython#101039
edmorley added a commit to edmorley/get-pip that referenced this pull request
Currently `get-pip.py` installs not only pip, but also setuptools and wheel by default, unless the `--no-setuptools` / `--no-wheel` (or `PIP_NO_SETUPTOOLS` / `PIP_NO_WHEEL` env vars) are used. This has historically been necessary, however, modern versions of pip will now fallback to `pyproject.toml` (PEP 517: [1]) based builds (which will default to a setuptools backend, and thus automatically install setuptools and wheel in the isolated build environment) if either setuptools is not installed (as of pip 22.1: [2]), or if wheel is not installed (as of pip 23.1: [3]). In addition, as of Python 3.12, the stdlib's `ensurepip` and `venv` modules no longer install setuptools, and only install pip ([4]). As such, it is now time for `get-pip.py` to stop installing setuptools and wheel by default on Python 3.12+, in order to: - Act as another small step towards `pyproject.toml` / PEP 517 based builds eventually becoming the pip default. - Improve parity with the behaviour of `ensurepip` / `venv` on Python 3.12+. - Allow `get-pip.py` to focus on its primary responsibility: bootstrapping Pip. Closes pypa#200. [1]: https://peps.python.org/pep-0517/ [2]: pypa/pip#10717 [3]: pypa/pip#11871 [4]: python/cpython#101039
edmorley added a commit to heroku/buildpacks-python that referenced this pull request
Currently the buildpack performs a system site-packages install of not only pip, but also setuptools and wheel. This has historically been necessary for pip to be able to build source distributions (sdists) for packages that don't ship with compatible wheels. However: - Thanks to PEP 518, packages can now (and many already do) specify an explicit build backend using `[build-system]` in their `pyproject.toml`. The dependencies specified in that config (such as setuptools and wheel) will be installed by pip into an isolated and ephemeral build environment as part of the source distribution build process. Such packages therefore don't need/use globally installed setuptools/wheel versions. - As of pip v22.1, pip will now default to the isolated build environment mode (along with a fallback legacy setuptools build backend), if the setuptools package isn't installed globally. This means that packages that haven't yet migrated to a PEP 518 `pyproject.toml` build backend config can still build even if setuptools isn't installed globally. There are a small number of rarely used packages in the wild that aren't compatible with build isolation mode, however, these typically require more build dependencies than just setuptools, which means they wouldn't have worked with this buildpack anyway. As such, it's no longer necessary for us to install setuptools and wheel globally. This matches the behaviour of the `venv` and `ensurepip` modules in Python 3.12+, where setuptools and wheel installation has also been removed. And it also matches the default behaviour of Poetry too, whose `install --sync` command removes any implicitly installed packages in the current environment (other than pip). See: https://peps.python.org/pep-0518/ https://pip.pypa.io/en/stable/reference/build-system/ https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/#build-isolation pypa/pip#10717 python/cpython#101039 pypa/get-pip#218 astral-sh/uv#2252 GUS-W-16437776.
edmorley added a commit to heroku/buildpacks-python that referenced this pull request
Currently the buildpack performs a system site-packages install of not only pip, but also setuptools and wheel. This has historically been necessary for pip to be able to build source distributions (sdists) for packages that don't ship with compatible wheels. However: - Thanks to PEP 518, packages can now (and many already do) specify an explicit build backend using `[build-system]` in their `pyproject.toml`. The dependencies specified in that config (such as setuptools and wheel) will be installed by pip into an isolated and ephemeral build environment as part of the source distribution build process. Such packages therefore don't need/use globally installed setuptools/wheel versions. - As of pip v22.1, pip will now default to the isolated build environment mode (along with a fallback legacy setuptools build backend), if the setuptools package isn't installed globally. This means that packages that haven't yet migrated to a PEP 518 `pyproject.toml` build backend config can still build even if setuptools isn't installed globally. There are a small number of rarely used packages in the wild that aren't compatible with build isolation mode, however, these typically require more build dependencies than just setuptools, which means they wouldn't have worked with this buildpack anyway. As such, it's no longer necessary for us to install setuptools and wheel globally. This matches the behaviour of the `venv` and `ensurepip` modules in Python 3.12+, where setuptools and wheel installation has also been removed. And it also matches the default behaviour of Poetry too, whose `install --sync` command removes any implicitly installed packages in the current environment (other than pip). See: https://peps.python.org/pep-0518/ https://pip.pypa.io/en/stable/reference/build-system/ https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/#build-isolation pypa/pip#10717 python/cpython#101039 pypa/get-pip#218 astral-sh/uv#2252 GUS-W-16437776.
edmorley added a commit to heroku/buildpacks-python that referenced this pull request
Currently the buildpack performs a system site-packages install of not only pip, but also setuptools and wheel. This has historically been necessary for pip to be able to build source distributions (sdists) for packages that don't ship with compatible wheels. However: - Thanks to PEP 518, packages can now (and many already do) specify an explicit build backend using `[build-system]` in their `pyproject.toml`. The dependencies specified in that config (such as setuptools and wheel) will be installed by pip into an isolated and ephemeral build environment as part of the source distribution build process. Such packages therefore don't need/use globally installed setuptools/wheel versions. - As of pip v22.1, pip will now default to the isolated build environment mode (along with a fallback legacy setuptools build backend), if the setuptools package isn't installed globally. This means that packages that haven't yet migrated to a PEP 518 `pyproject.toml` build backend config can still build even if setuptools isn't installed globally. There are a small number of rarely used packages in the wild that aren't compatible with build isolation mode, however, these typically require more build dependencies than just setuptools, which means they wouldn't have worked with this buildpack anyway. As such, it's no longer necessary for us to install setuptools and wheel globally. This matches the behaviour of the `venv` and `ensurepip` modules in Python 3.12+, where setuptools and wheel installation has also been removed. And it also matches the default behaviour of Poetry too, whose `install --sync` command removes any implicitly installed packages in the current environment (other than pip). See: https://peps.python.org/pep-0518/ https://pip.pypa.io/en/stable/reference/build-system/ https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/#build-isolation pypa/pip#10717 python/cpython#101039 pypa/get-pip#218 astral-sh/uv#2252 GUS-W-16437776.
This was referenced
This file contains hidden or 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