Python 3.12 omits pip entry point on macOS

[culler]

Bug report

Bug description:

Whether building Python 3.12 from source or installing it from python.org, there is no pip executable in the bin directory. There is a pip3. But many installation instructions on the web say to use pip, and many users are used to doing that. The unfortunate consequence is that if a user has both the 3.11 and the 3.12 versions in their path (as happens with installs from python.org) then they will be installing packages for 3.11 when they use pip.

CPython versions tested on:

3.12

Operating systems tested on:

macOS

[ned-deily]

There's no python either, just python3 or python3.x. Within a venv, both python and pip are available.

[ned-deily]

That's just another reason why we should be deprecating the use of plain pip in favor of python3 -m pip.

[culler]

If calling the pip executable were to cause a deprecation message to be printed, that might help train people.

However, I am not a big fan of naming the executable python3 rather than python. When python 2 is gone, the 3 is redundant. And why should an old abandoned version of python be awarded the more desirable name? The language is still named Python, not Python3, if I am not mistaken. I always install python-is-python3 on my Ubuntu systems.

[ned-deily]

BTW, PEP 394 addresses the topic of python vs python3. After over ten years and the completion of the transition to Python 3, it may be time to revisit it.

[ronaldoussoren]

A reason to install pip would be that upgrading pip by runningpython3.x -m pip install -U pip will install pip as well as pip3 and pip3.13. Installing pip in the installer as well brings a more consistent user experience.

Looking at the code in postflight.ensurepip that script currently explicitly removes the pip script in the framework due to an earlier issue about user confusion when both Python 2 and Python 3 are installed. IMHO that's no longer a relevant consideration and we can install "pip" as a name as well.

That said, this would require a change to ensurepip as that script won't install the "pip" alias. I'd not be in favour of unilaterally changing the install behaviour for just macOS.

[ned-deily]

I think we should ask for a pronouncement from the Steering Council about the direction for unversioned names (python, idle, pip, et al) on non-Windows platforms (outside of an activated venv) going forward before making a unilateral change just for macOS, perhaps with a PEP 394 update proposal. Or perhaps there already is a pronouncement?

cc: @python/steering-council

[gpshead]

Do we ever envision a world where installing/updating pip itself does not add a pip executable? If not, we should be consistent with that and ship one as Ronald points out. Otherwise the result is just a confusing state machine.

[ronaldoussoren]

Do we ever envision a world where installing/updating pip itself does not add a pip executable? If not, we should be consistent with that and ship one as Ronald points out. Otherwise the result is just a confusing state machine.

I don't because upgrading pip without installing a pip executable would break too many expectations. But, I'm not a pip maintainer. @pfmoore might be able to chime in on this.

Cross platform consistency is another thing to consider. Looking at the details of Fedora's python3-pip package it seems that the default behaviour on Fedora is to have /usr/bin/pip as one of the executables installed.

Changing to unversioned names for the other executables (python, pip, pydoc) is another question and is one that should not be a unilateral change for macOS. I'd personally prefer to have unversioned binaries outside of virtual environments as well.

[pfmoore]

There's a long-running pip issue, pypa/pip#3164, for deprecating the executables, but personally I think it's unlikely to happen in the foreseeable future, as it would break too many expectations.

I think it makes sense to install a pip executable, but I use Windows so the nuances of PEP 394 and the history on Unix-like systems is unfamiliar to me.