Create an App Execution Alias for `pip` to `py -m pip`

[kenblu24]

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

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

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

---

Additional context

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

From the 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 the python problem, and thus would work anywhere py.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 a pip execution alias, but if it's possible, it seems like it would come with the same or fewer challenges as the python 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 alongside py and python would align with the expectation that the automatically installed version provides pip at the command line.

The PEP notes that the current Windows Store installs provide pip, 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 usable python command out of it, so what's the point? The previous deal was that if you want python in your path, you also get pip by default, unless you _un_check that pip box.

For users that want python but not pip, 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 of pip availability differently than python itself is a little confusing to me.

pip usage in non-official tutorials and scripts

Personally, I rarely see python -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 seen py -m pip ... recommended anywhere except this thread. But then again I've never seen py used in any tutorial or SE post. I didn't even know Ubuntu had a pythonpy package for the alias until just now when I tried to run py on it.

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

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 like flake and pipenv.

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 teaching python -m pip would be conducive to users remembering to run python -m virtualenv for example. But also, I find the idea of having to type python -m pip uv install on a regular basis in a few years quite gross.

A lot of these tools, such as pipx and uv, will likely do whatever it takes to ensure that they, along with the packages they install, are available to the user without requiring python -m. But right now, Windows users who can run python can also run pip install virtualenv; virtualenv . rather than python -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 get uv as soon as possible.

[zooba]

Yeah, this isn't an unreasonable idea.

The biggest limitation is that we're actually at the limit of separate entry points the Store will let us put in a single application. Previously I had all the py/python/python3/pymanager aliases going to the same entry point, but that didn't allow for some of the error messages to be perfect and so they had to be split up. Along with the w equivalents, we're at the limit.

There's also the impact of adding more entries to the Settings page ("Manage app execution aliases"), which is unfortunately not optimised for any more than 5-6 entries total (I personally have maybe 50 entries and it's pretty unusable).

What would probably be better is to generate a new set of redirectors, that could live along with the python3.X.exe generated files. These could be done for all registered console entry points, and could theoretically support the -V:<TAG> argument to let you select the matching runtime (though this then hits the complexity of the package not being installed for all your runtimes, so what happens when you select the wrong one?). Also, some tools probably won't like losing the ability to have those options appear first - we have a general consensus that CPython won't use them, but obviously can't get that from every package that's ever been released.

@pfmoore Do you have any thoughts/preferences here? I know we discussed "how do people know what command to run" a few times, and while I personally think the -m option is the best for all cases, obviously the queries are not going to go away (and are predominantly going to involve pip, I predict).

[pfmoore]

From pip's side, we've tried, and spectacularly failed, to promote python -m pip as the "correct" invocation for pip. At this point, I think we have to accept that people want a pip command, and do what we can to provide it.

I think it's essential that the pip command runs pip in exactly the same environment as the python command, and py, default to. Anything else will cause immense user confusion. I don't think we should support -V:<tag> on the pip command (or indeed any non-standard options. If people want to run pip for a different Python environment, they should activate that environment or use python -m pip to explicitly choose the interpreter they want to use. I am strongly against any sort of "versioned" pip commands, whether it's pip -V:3.13 or pip3.13. Those cause far more trouble than they are worth.

I'm not a huge fan of having the availability of the pip command be tied to making python3.X redirectors available. At the moment, adding the directory with the redirectors to your PATH is solely for versioned aliases, and I think that makes the decision over whether to add it a lot simpler for users. Changing it to "... if you want python3.X aliases or the pip command" makes it a harder decision, and doesn't provide an answer for the case where the user wants pip, but not the versioned aliases.

How will users add other script wrappers, like pipx or pytest, to their path? Are we expecting them to add <sys.prefix>/Scripts to their PATH manually? And if so, then will the app alias or the PATH entry take precedence? In theory it shouldn't matter, but can we write an app alias that ensures that? I.e., one that runs pip for the same environment that the PATH entry uses?

Lots of questions, but no good answers, I'm afraid. But I do agree with the OP, that making a pip command available by default is important - so "leave it to the user to configure their path" is insufficient, IMO.

[zooba]

How will users add other script wrappers, like pipx or pytest, to their path? Are we expecting them to add <sys.prefix>/Scripts to their PATH manually?

This was where I was heading with the "new set" of redirectors, which would probably involve PyManager scanning all known installs for entry point registrations and generating them itself. We'd probably have to do some command line scanning to trigger automatically, which would have gaps, but py install --refresh would be the way to manually do it.

But yes, for now, we're expecting users to add sys.prefix/Scripts to their PATH if they want it. We're actually hoping they'll just activate a virtual environment, and that's what the docs are biased towards, but pip will print the path to add if it isn't present (and it's stable enough that it's okay to add manually, provided people get their ordering correct and remember to remove it).

so "leave it to the user to configure their path" is insufficient, IMO

First-time run of PyManager now prompts people to add its versioned commands directory to PATH, so it's not quite leaving it to the user (though people are already managing to skip it and wonder why we aren't offering to help them, so maybe it needs to be more invasive...). And a generated pip[X.Y].exe in that directory has the advantage of still being available if you remove PyManager but keep the installs.

It could also be specified in install metadata, which leaves things open to anyone to extend (for their own index) for other scripts. I don't particularly like making pip too special on its own, but we genuinely can't keep adding global commands.