pip wheels (from ensurepip) show nonexistant entry_points in importlib.metadata

Description

I was working on some code (a conan generator to write cmake add_executable(... IMPORTED) bindings based on importlib.metadata.entry_points), and noticed something odd - there was an entry point for pip3.8 showing up that didn’t actually have a corresponding launcher pip3.8.exe (since I was/am stuck using python 3.7 to avoid https://github.com/pypa/pip/issues/8649 until a cpython release picks up pip 21.2, the actual launcher was pip3.7.exe).

Expected behavior

importlib.metadata.Distribution.entry_points will correspond to the entry_point launchers that actually exist.

pip version

20.2.3-21.2.4

Python version

3.9.4

OS

Windows

How to Reproduce

from importlib.metadata import distribution
distribution("pip").entry_points

note the presence of EntryPoint(name='pip3.8', value='pip._internal.cli.main:main', group='console_scripts'), even though this is python 3.9, not 3.8.

where pip3.8
INFO: Could not find files for the given pattern(s).
>where pip3.9
C:\Program Files\Python39\Scripts\pip3.9.exe

Output

[EntryPoint(name='pip', value='pip._internal.cli.main:main', group='console_scripts'), EntryPoint(name='pip3', value='pip._internal.cli.main:main', group='console_scripts'), EntryPoint(name='pip3.8', value='pip._internal.cli.main:main', group='console_scripts')]

entry_points.txt

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

The wheel for 21.2.4 still seems to show the same sort of thing going on: https://files.pythonhosted.org/packages/ca/31/b88ef447d595963c01060998cb329251648acf4a067721b0452c45527eb8/pip-21.2.4-py3-none-any.whl (though there it’s pip3.9 that is present)

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pradyunsg]

Cool. Given that everyone on this thread doesn’t think this is important or worth fixing, let’s close this?

[pfmoore]

Yes, that’s because we generate versioned values in entry_points.txt which are not needed when we generate the scripts, but (as I understand it from @uranusjr’s comment) are used by Linux distributions, who build the wheels, but don’t use pip to install them, but rather extract the wheel using their own process (which presumably relies on the entry points).

I’m saying that to be correct, our entry point should just be pip (because entry points cann’t be dependent on the installation environment), but if we did that those Linux distributions would have to make new arrangements to generate the right scripts.