Older (yet still supported) versions of pip crash when invoked through the alias.

[hungarian-notation]

Install source and version

• Installed from the Windows Store
• Installed with the MSIX from python.org
• Installed with the MSI from python.org
• Installed with winget install 9NQ7512CXL7T

Version: 26.3

Describe the bug
Broken global pip when installing some versions of python.

Pip 23.0.1 from Python 3.10 crashes when invoked through its alias with the following trace:

Traceback (most recent call last):
  File "C:\Users\WDAGUtilityAccount\AppData\Local\Python\bin\pip.exe.__script__.py", line 33, in <module>
    from pip._internal.cli.main import main
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1002, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 945, in _find_spec
  File "C:\Users\WDAGUtilityAccount\AppData\Local\Python\pythoncore-3.10-64\lib\site-packages\_distutils_hack\__init__.py", line 97, in find_spec
    return method()
  File "C:\Users\WDAGUtilityAccount\AppData\Local\Python\pythoncore-3.10-64\lib\site-packages\_distutils_hack\__init__.py", line 145, in spec_for_pip
    if self.pip_imported_during_build():
  File "C:\Users\WDAGUtilityAccount\AppData\Local\Python\pythoncore-3.10-64\lib\site-packages\_distutils_hack\__init__.py", line 157, in pip_imported_during_build
    return any(
  File "C:\Users\WDAGUtilityAccount\AppData\Local\Python\pythoncore-3.10-64\lib\site-packages\_distutils_hack\__init__.py", line 158, in <genexpr>
    cls.frame_file_is_setup(frame) for frame, line in traceback.walk_stack(None)
  File "C:\Users\WDAGUtilityAccount\AppData\Local\Python\pythoncore-3.10-64\lib\site-packages\_distutils_hack\__init__.py", line 167, in frame_file_is_setup
    return frame.f_globals.get('__file__', '').endswith('setup.py')
AttributeError: 'NoneType' object has no attribute 'endswith'

To Reproduce

• I paste python-manager-26.3.msi into a fresh Windows Sandbox.
• I run the installer.
• I run py install 3.10
• I add C:\Users\WDAGUtilityAccount\AppData\Local\Python\bin to PATH
• I run pip, causing the crash.

Additional context
I did not interact with the sandbox VM in any way besides pasting the installer, opening and reopening Powershell, and running the commands as described above.

combined console transcript of reproduction

[zooba]

Hmm, I guess this is related to the changes we made to make multiprocessing work here.

Perhaps del __file__ instead of __file__ = None is going to be safer across more cases?

If the installer is going to maintain a pip in my path it should not crash when invoked. Perhaps it should not maintain a pip in my path at all, as this is not the only buggy or surprising thing it does.

No need to be passive aggressive like this, it's only going to annoy us and get you banned from the repository. You can just be polite instead, it's not that hard, even if you are feeling frustrated. (Despite this, we do greatly appreciate you taking the time to report these issues, and doing it clearly and precisely. It's just let down by also having a go at the volunteers who look after it.)

You can disable the entrypoints if you don't like them by putting {"install": {"enable_entrypoints": false}} in your configuration file. I personally would prefer we didn't try to maintain these aliases, but more than enough people complained about them being missing that we had to do something.

[hungarian-notation]

Apologies, I did not intend it to come across that way. I was admittedly a bit tired when writing these up last night though, and reading it back now I 100% agree that it comes off as rude.

I appreciate the work you guys are doing. The fact that I can get any supported python version running on a fresh Windows sandbox within seconds of creating it is legitimately a massive win.

The idea I was actually trying to express is, given the understanding that python -m pip is generally a better way to invoke pip even without the installation manager, it might make sense to dissuade the use of a more mutable than usual root environment pip from the path as a matter of design. I'm a big fan of the environment variable that prevents you from accidentally installing packages to the root environment for similar reasons.

That is however just my opinion and not relevant to the bug.

The qualifier added onto what was intended as a terse statement of the obvious expected behavior was, in my head, meant to say that I'm not sure you should simply fix this. That was more relevant to the version confusion bug though, so I clarified the idea there instead, leaving me sounding like an ass here.

[zooba]

Thanks, I appreciate your response.

The idea I was actually trying to express is, given the understanding that python -m pip is generally a better way to invoke pip even without the installation manager, it might make sense to dissuade the use of a more mutable than usual root environment pip from the path as a matter of design.

Yeah, and I do agree with you. The first 1-2 years of releases didn't try to generate those aliases at all, because py -m pip is more predictable and reliable, as is activating a virtual environment, but the demand for just wanting the commands to work was so high it couldn't be ignored.

Since then, unsurprisingly, there have been bugs in every release, though at least they're becoming more obscure each time. And IMHO they're all more obscure than having multiple entries in PATH that have gone out of order, so we're in a better place than previously. Just need to burn down the rest of the issues.

FWIW, the fix for this in the linked PR is quite simple, and you can apply it to the pip.exe.__script__.py-like files you'll find in the globals directory (on your PATH). I see no reason why it wouldn't work fine in your case, I'm far more worried about everyone else who's currently working and could be broken, but if you want to check the change before we merge it that'd be helpful.