Is your feature request related to a problem? Please describe.
Users will want to runpip instead of typingpython -m pip.

Describe the solution you'd like
If a user has runpython on a Windows computer before, then they should be able to runpip as well.

Describe alternatives you've considered
See#121 "Includepip in PATH"

Additional context

Is there any reason whypip.exe can't get the same treatment thatpy.exe does? Ifpy.exe gets installed to WindowsApps and is available through App Execution Aliases, then why can't we have apip.exe reside there as well, which could just be an alias topy -m pip?

Fromthe PEP:

The Windows Store package is very reliable, with the exception of the global shortcuts. Rather than modifying PATH to add its own directory, these shortcuts are created in a single OS managed directory that has all the shortcuts defined by any app. Users are able to modify their PATH to exclude or de-prioritise this directory, leading to unreliable or inconsistent behaviour, and historically we have also seen this caused by installers. For example, installing Python from the Store followed by Python from the traditional installer with its PATH modification enabled will almost always shadow the Store package’s Python with the later install.

It'll adhere to your ethos of not modifying PATH, same as the way you solve thepython problem, and thus would work anywherepy.exe would. It would also be overridden by user modifications to PATH. Excuse me as I'm not familiar with any roadblocks for PyManager providing apip execution alias, but if it's possible, it seems like it would come with the same or fewer challenges as thepython execution alias.

Rationale

I assume there's a cost to implement this, both in dev time, support, etc. So I provide my unsolicited thoughts as to why I think it's worth it:

User expectation compared to current Python install methods

Providing this alias alongsidepy andpython would align with the expectation that the automatically installed version providespip at the command line.

ThePEP notes that the current Windows Store installs providepip, as do MSI installs which have both of the

• pip
• Add Python to path

boxes checked.

Specifically, the PEP says:

no global pip command is included (the traditional installer also does not include a global pip command, unless the options to modify PATH and to install pip are selected; the first of these is off by default).

Even though Add Python to path is unchecked by default, users that don't check that box also don't get a usablepython command out of it, so what's the point? The previous deal was that if you wantpython in your path, you also getpip by default, unless you _un_check thatpip box.

For users that wantpython but notpip, I don't think asking them to add a command line option, set an environment variable, or set a config file option is too big of a deal.

Most of the PEP makes sense to me, but treating user expectation ofpip availability differently thanpython itself is a little confusing to me.

pip usage in non-official tutorials and scripts

Personally, I rarely seepython -m pip ... recommended anywhere online. The only exception in I have seen in recent memory is when pip tells me to upgrade it.

Furthermore, I have never seenpy -m pip ... recommended anywhere except this thread. But then again I've never seenpy used in any tutorial or SE post. I didn't even know Ubuntu had apythonpy package for the alias until just now when I tried to runpy on it.

For the sake of consistency with onlinepip install x instructions, it'd be nice to assume users have the ability to run barepip on Windows so long as they havepython. I'd hate to imagine a future where I have to tell Windows users in particular to runpy -m pip while everyone else can just typepip.

Downsides

Other tools

It's worth noting that this doesn't solve the problem of tools not being on PATH.

Many Python tools make commands available. See:https://packaging.python.org/en/latest/guides/installing-stand-alone-command-line-tools/ which mentions tools likeflake andpipenv.

Far be it from me to suggest that all the existing tools which do so should have an app execution alias. So I concede that teachingpython -m pip would be conducive to users remembering to runpython -m virtualenv for example. But also, I find the idea of having to typepython -m pip uv install on a regular basis in a few years quite gross.

A lot of these tools, such aspipx anduv, will likely do whatever it takes to ensure that they, along with the packages they install, are available to the user without requiringpython -m. But right now, Windows users who can runpython can also runpip install virtualenv; virtualenv . rather thanpython -m pip install virtualenv; python -m virtualenv. It'd be sad if the latter is the most platform-agnostic command. Surely there's a better way, lest I just tell students to getuv as soon as possible.