Repository navigation
Create an App Execution Alias for pip to py -m pip #140
Description
Activity
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/pymanageraliases 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 thewequivalents, 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.exegenerated 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
-moption is the best for all cases, obviously the queries are not going to go away (and are predominantly going to involve pip, I predict).From pip's side, we've tried, and spectacularly failed, to promote
python -m pipas the "correct" invocation for pip. At this point, I think we have to accept that people want apipcommand, and do what we can to provide it.I think it's essential that the
pipcommand runs pip in exactly the same environment as thepythoncommand, andpy, 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 usepython -m pipto explicitly choose the interpreter they want to use. I am strongly against any sort of "versioned" pip commands, whether it'spip -V:3.13orpip3.13. Those cause far more trouble than they are worth.I'm not a huge fan of having the availability of the
pipcommand be tied to makingpython3.Xredirectors 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 wantpython3.Xaliases 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>/Scriptsto 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
pipcommand available by default is important - so "leave it to the user to configure their path" is insufficient, IMO.How will users add other script wrappers, like pipx or pytest, to their path? Are we expecting them to add
<sys.prefix>/Scriptsto 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 --refreshwould be the way to manually do it.But yes, for now, we're expecting users to add
sys.prefix/Scriptsto theirPATHif 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].exein 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
piptoo special on its own, but we genuinely can't keep adding global commands.
Is your feature request related to a problem? Please describe.
Users will want to run
pipinstead of typingpython -m pip.Describe the solution you'd like
If a user has run
pythonon a Windows computer before, then they should be able to runpipas well.Describe alternatives you've considered
See #121 "Include
pipin PATH"Additional context
Is there any reason why
pip.execan't get the same treatment thatpy.exedoes? Ifpy.exegets installed to WindowsApps and is available through App Execution Aliases, then why can't we have apip.exereside there as well, which could just be an alias topy -m pip?From the PEP:
It'll adhere to your ethos of not modifying PATH, same as the way you solve the
pythonproblem, and thus would work anywherepy.exewould. It would also be overridden by user modifications to PATH. Excuse me as I'm not familiar with any roadblocks for PyManager providing apipexecution alias, but if it's possible, it seems like it would come with the same or fewer challenges as thepythonexecution 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
pyandpythonwould align with the expectation that the automatically installed version providespipat the command line.The PEP notes that the current Windows Store installs provide
pip, as do MSI installs which have both of theboxes checked.
Specifically, the PEP says:
Even though Add Python to path is unchecked by default, users that don't check that box also don't get a usable
pythoncommand out of it, so what's the point? The previous deal was that if you wantpythonin your path, you also getpipby default, unless you _un_check that pip box.For users that want
pythonbut 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 of
pipavailability differently thanpythonitself is a little confusing to me.pipusage in non-official tutorials and scriptsPersonally, 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 seenpyused in any tutorial or SE post. I didn't even know Ubuntu had apythonpypackage for the alias until just now when I tried to runpyon it.For the sake of consistency with online
pip install xinstructions, it'd be nice to assume users have the ability to run barepipon 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 pipwhile 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 like
flakeandpipenv.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 pipwould be conducive to users remembering to runpython -m virtualenvfor example. But also, I find the idea of having to typepython -m pip uv installon a regular basis in a few years quite gross.A lot of these tools, such as
pipxanduv, 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 runpythoncan 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 getuvas soon as possible.