Building Python3.11.0 with ensurepip incorrectly includes bin/pip3.10

[mkillianey]

Bug report

Building Python3.11.0 with --ensure-pip seems to incorrectly createpip3.10 in addition to pip3 and pip3.11, where pip3.10 is identical to pip3.11.

Building Python3.11 at v3.11.0:

$ git log -n1 --oneline
deaf509e8f (HEAD, tag: v3.11.0) Python 3.11.0
$ ./configure --prefix=/tmp/python3.11 --with-ensurepip && make install 
...omitted...
$ make install
...omitted...
Installing collected packages: setuptools, pip
  WARNING: The scripts pip3, pip3.10 and pip3.11 are installed in '/tmp/python3.11/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
...omitted...

Observing the problem:

$ ls -1 /tmp/python3.11/bin/pip*
/tmp/python3.11/bin/pip3
/tmp/python3.11/bin/pip3.10
/tmp/python3.11/bin/pip3.11
$ diff -s /tmp/python3.11/bin/pip3.1{0,1}
Files /tmp/python3.11/bin/pip3.10 and /tmp/python3.11/bin/pip3.11 are identical
$ head -n1 /tmp/python3.11/bin/pip3.10
#!/tmp/python3.11/bin/python3.11

Your environment

Building on linux-x86_64.

[mkillianey]

I also see this behavior at the current head of the 3.11 branch: 4fc042f but not at the current head of the main branch (ccab67b), where only pip3 and pip3.12 are installed.

[mkillianey]

Hmm, actually, a correction -- my main branch was behind. At tag v3.12.0a1 (commit 4ae1a0e), building Python installs pip3, pip3.10, and pip3.12.

[mkillianey]

Bisecting suggests that the extra pip3.10 was introduced with the commits that upgrade setuptools and pip:
c954335 (on 3.11 branch)
9da5215 (on main branch)

[hugovk]

Looking at the contents of Lib/ensurepip/_bundled/pip-22.3-py3-none-any.whl in 9da5215 (by adding a .zip extension), pip22.3.dist-info/entry_points.txt says:

[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
pip3.10 = pip._internal.cli.main:main

[uranusjr]

Looks like a pip bug. pip contains logic to specially fix pipX.Y (and easy_install-X.Y) entry points to correctly match the Python version, but that logic only accounts for single-digit version numbers and doesn’t work with 3.10 upwards. We didn’t notice this earlier because pip bundled in 3.10 was built against 3.10 and no dynamic replacement was needed, but pip 22.3 (bundled in 3.11.0) was built against 3.10, not 3.11, exposing the bug.

https://github.com/pypa/pip/blob/ff207cff2aeea05f13a246a99f24e6944492b18e/src/pip/_internal/operations/install/wheel.py#L328

[uranusjr]

Fix submitted to pypa/pip#11547

[mkillianey]

Gentle suggestion:

Although the problem's roots are in pip, given that the problem is the way the pip wheel was built (with Python3.10), could we patch the wheel in the repo to fix this problem, so that we don't have to wait for a new pip release?

I just verified locally that removing the pip3.10 entry point from pip-22.3-py3-none-any.whl seems to solve the problem on my machine:

unzip Lib/ensurepip/_bundled/pip-22.3-py3-none-any.whl pip-22.3.dist-info/entry_points.txt
sed -i '/pip3\.10/d' pip-22.3.dist-info/entry_points.txt
zip Lib/ensurepip/_bundled/pip-22.3-py3-none-any.whl pip-22.3.dist-info/entry_points.txt

[uranusjr]

It’s plausible. The RECORD file should also be patched for the hash to match; pip does not verify the value, but it’s better for correctness.

[2-5]

It seems this problem also affects the Windows install binaries.

I installed 3.11 using python-3.11.0-amd64.exe and the following pip binaries are present:

• Scripts\pip.exe
• Scripts\pip3.exe
• Scripts\pip3.10.exe
• Scripts\pip3.11.exe

[zooba]

Is this still an issue? We've updated pip at least a couple of times since early 2023.

[hugovk]

Looking at the contents of Lib/ensurepip/_bundled/pip-22.3-py3-none-any.whl in 9da5215 (by adding a .zip extension), pip22.3.dist-info/entry_points.txt says:

[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
pip3.10 = pip._internal.cli.main:main

Repeating for main, pip-23.3.2.dist-info/entry_points.txt contains:

[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
pip3.11 = pip._internal.cli.main:main

pip3.11 is also in the 3.12 and 3.11 branches.

Is this a problem?

[uranusjr]

pip automatically excludes pipX and pipX.Y entry points when it installs itself, so the pip3.11 line should not affect things in practice. The original bug was due to pip having faulty logic for ignoring the entry points. This has been fixed on pip’s side, and the up-to-date versions bundled in CPython branches do not contain the bug now.

[zooba]

Sounds fixed then. If it repros, we can look again.