The pip developers are currently exploring options for a new deployment method for pip, probably in the form of a zipapp or similar standalone mechanism. This will not (at least in the short term) replace the existing approach of installing pip in your environment, but it will offer an alternative for people who prefer not to have copies of pip installed everywhere.
The new approach won’t appear before the 22.3 release of pip (October 2022), but we wanted to give advance notice, as this change has the potential to affect what people (and tools) can expect - at the moment, it’s reasonable to assume that pip is present in any Python environment, and
python -m pip will run pip anywhere. With a standalone pip application, this will no longer be the case.
So we’d be interested in any feedback on how this could affect people’s workflows, or tools. To reiterate, we’re not expecting to change the official deployment method in the short term, but we will be offering (and supporting) other approaches, and we’d like to get a better feel of the impact so that we can determine how to plan the rollout and how to frame the announcements.
To be clear, we’re not asking for views on whether this would be a good idea - that’s going to be a decision we will make ourselves. But we do want to know about any examples of workflows that at the moment are tied to pip being installed in the environment, so that we can ensure that they are considered in any change that we do make. We’re also not planning at this point on any changes to the stdlib
ensurepip module, nor are we expecting to change the stdlib
venv module to stop installing pip by default. That sort of change may happen later, if the “standalone pip” approach proves popular and useful, but it’s not in our plans now.
In particular, responses along the lines of “I don’t agree with this approach” with no explanation, don’t really offer anything actionable that we can use. ↩︎