Repository navigation
Include pip in path #121
Description
Activity
Unfortunately, there is no "scripts" directory here. There's a global commands directory that Python runtimes are added to, but pip/etc. don't use (and it probably shouldn't, since it'd just make a mess), and no PATH modifications per-install (or we get back into the unreliable mess that the install manager gets us away from).
Use
py -m pipto launch pip. It also works for most other commands, and if it doesn't, report to the tool and they should be able to enable it easily. Or create a virtual environment and activate it, then you'll get itsScriptsdirectory onPATHfor your session, which is infinitely more robust than modifying settings permanently.
That said, this is sure to be a popular request, so I'm going to pin this issue so people can see the explanation. And if someone comes up with a brilliant idea on how to make it work, we're open to it, but automatically modifying
PATHisn't it.Reacted by minerharry- pinned this issue
on May 27, 2025 I am very excited to try Python Install Manager on Windows. Everything is ready, I installed Python 3.14, and when I tried to use pip, the Terminal reported an error. How frustrating, there were no prompts during the initialization process. Although there are a thousand reasons for the absence of pip, I just want to ask one question: If pip cannot be used conveniently, then why go to the trouble of using Python Install Manager?
Version management for Python on Linux and macOS has a lot of options, I believe their pip solution is worth referencing.
py -m pipshould invoke pip. Does it not?This command should be permanently displayed on the Usage page
Which Usage page do you mean? Which pages did you see that would have helped you know this command?
You can perform an upgrade if there is one
python -m pip install --upgrade pipor install enable-pippython -m pip enable-pip, either one will do. They both add the missing executables to the scripts folder in your python installation.Don't forget to add the scripts folder (
%localappdata%\Python\pythoncore-3.14-64\scripts) to your PATH afterwards and close and then open any open terminals.Reacted by jmmug-medscintIronically pip installs "pip.exe, pip3.14.exe and pip3.exe" into Scripts, which are very similar to what Python Install Manager is doing to python executable itself with "python.exe, python3.14.exe and python3.exe" - if only there was a way for the bin and scripts to work in unison...
I feel like since there is a "default installed version, which will be the latest stable release unless configured otherwise" - there should be a way to expose and manage the Scripts associated with it, otherwise it feels like Python Install Manager basically deprecates the entire Scripts functionality, whereas most users expect it and it works this way on majority of non-Windows systems.
I think there could be an elegant way to expose the Scripts similarly to what is done with bin, but perhaps by way of soft-linking the Scripts on the same level with bin, controlled by some new setting/env var such as PYTHON_MANAGER_EXPOSE_SCRIPTS for example...
In the screenshot below I created a symlink to the Scripts for the currently default Python - and than add that symlinked dir to PATH.
If Python Install Manager could maintain that symlink to always point to the same prefix path as in python.exe.target - that would totally solve this for me, as Scripts would automatically follow whatever the selected default python is.
Reacted by minerharryWe have to manage without symlinks, unfortunately. And linking a directory isn't something we can make reliable in the same way that the default Python is calculated, though we could potentially add a scan for entry points in all discovered Python runtimes and generate new script executors for them ourselves. Unfortunately, we can't automatically do that after a package install, unless pip/etc. learn to trigger a
pymanager install --refreshcommand after install (which they could... @pfmoore thoughts?)Ultimately, the best workaround here is to use a virtual environment.
py -m venv ...is the only way to create one already, and once activated, you'll haveScriptson PATH for your session.I don't think it's reasonable to tie pip (and every other installation tool that might exist) to the
pymanagercommand like this. Maybe if there was a core API in the stdlib that tools could call, installers could use that? But I don't know how we could have such an API without requiring distributors who didn't use the pymanager installer to patch the stdlib. Ultimately someone has to answer the question "is this environment one that requires something to be done whenever a new script is installed?" and the only sustainable way to have that work is if the stdlib (or more precisely, the python installation present in the environment) offers an API to answer that question (and do whatever needs to be done).I do agree with the @akrymskiy here that by adding the
pythoncommand to the user's path, we're setting expectations that the experience will be the same as the old "add Python to PATH" option - and in particular that theScriptsdirectory will be available as well. We can blame OS limitations as much as we like, but the reality is that users who addpythonto their path are getting reduced functionality compared to the old installer. Ultimately, we made a choice to remove functionality that a lot of users found useful, in order to avoid some rare but difficult to deal with problems (the "unreliable mess" you refer to above, which frankly isn't something that most users ever noticed). We can debate whether that was a good choice, but I don't think we can claim that we didn't make that choice. Microsoft didn't force us to use the newer MSIX install format, we did so aware of its benefits and its limitations.Presumably the user can simply add the interpreter's
Scriptsdirectory to theirPATHmanually? Maybe we can provide some sort of utility or stdlib function that makes it easier to discover and use this option? Or maybepymanager installcould print a reminder that the new installation'sScriptsdirectory isn't onPATHby default, and describe how to add it if the user wishes to?Presumably the user can simply add the interpreter's Scripts directory to their PATH manually? Maybe we can provide some sort of utility or stdlib function that makes it easier to discover and use this option?
Yes, and pip already prints a message saying to do this. Apparently, this is for people who haven't gotten as far as running pip.
I don't think we can reasonably print more messages from PyManager and expect users to read them - it's just covering ourselves so we can say "it was there, in the middle of seven pages of output, so it's not our fault", which I'd rather not get into.
Plus, there's no intrinsic requirement that a runtime have a
Scriptsdirectory (there's none built into the CPython packages, since it would only include a brokenpip.exe, so we can't detect that it's there after install). We'd need some way to signal that a particular runtime should print that message, and resolve that in the context of multiple simultaneous installs.I'm leaning more towards the "scan all known runtimes for entry point specs and generate them ourselves". It would only be on runtime install/refresh, but that would at least include the initial install and would get a usable pip.exe created (which I'm sure will upset people who don't expect it to appear on their PATH, and no doubt we'll get security reports when other packages start showing up on PATH, but if the demand is strong enough then we can argue those away, and it's all opt-in to begin with anyway). When a new script is installed, users will just have to run
py install --refreshif the installers are not going to run it for them.That sounds reasonable. I think we should be very careful here to ensure that whatever we do design is based on what users actually want, rather than what we think they want. And it's notoriously hard to get a representative view of that 🙁
IMO, there are going to be three key groups of users who we'll need to consider:
- People who don't want anything beyond
pyon their path. They are easy to deal with, we do nothing and we're fine. - People who want
pythonandpythonX.Yon their path, but don't want a bunch of script entry points (of which pip is only one). These people are happy now, and if we start adding script entry points, they could be annoyed. This will also likely include the group who will have security concerns if installing a Python module can end up shadowing an existing command. Again, we can do nothing, because it's current behaviour. - People who want the same behaviour as the old installer, with
pythonandpipcommands available. My guess is that this group will include a huge number of people who only ever need a single Python version, and don't really care about the complexities ofPATHbut just want "the normal Python commands" to be available everywhere. This is likely to be the group that's least able to handle managingPATHfor themselves. Adding some way for this group to get what they want is the important point here, but IMO we shouldn't do so in a way that removes the behaviour group (2) prefers.
That means we should make "add entry point executables" opt-in, above and beyond the existing "add the
pythoncommand to your path" option. I think we need to avoid having a million different options here, but the three above are all plausible, and we should support them (just no more than this!)There's also a bunch of technical issues around how all of this would work for users who have multiple versions of Python installed, or who switch Python version frequently, or who add the aliases for one specific use case and forget to disable them afterwards, etc. But IMO we can make reasonable technical choices on those questions without getting bogged down in "what do people want" questions - there's no strong precedent from the old installers to worry about, and the people doing things like this are technically aware enough to work with whatever we choose (as long as we document things clearly, of course 🙂).
It's worth noting that the layout of the base Python environment is what results in there being 3 options here. The base executable is in
sys.prefix, and entry points are insysconfig.get_path("scripts"). The options basically cover which of these you add to your path (none, one or both) if you were managing executables manually. We (the core team, via the design of distutils) chose to have two locations, so we should be prepared to deal with the consequences of that.- People who don't want anything beyond
4 remaining items
1 and 2 are currently available to see - make sure you don't have the directory in PATH and run
py install --configure. If you choose to add the directory, you get 2, if you choose not to, you get 1.I'm proposing that those become 1 and 3, and those who want 2 (
pythonX.Y.exeshortcuts withoutpipX.Y.exeetc. shortcuts) have to also put something like{"install": {"disable_shortcut_kinds": ["site-dir"]}}into their config file. And obviously that magic setting gets documented somewhere, but I don't think we have to add UX somewhere for it.We don't actually have a reliable mechanism to generate the
X.Yversions of these shortcuts, but the entry points spec doesn't appear to require it anyway, so that'll simplify things nicely (apart from hiding which version of Python it's running in, but that's been a problem forever and we already have numerous ways to avoid that issue).We have to manage without symlinks, unfortunately.
I am curious as to why no symlinks? Is it due to the admin requirement? Could directory junctions be used instead as they don't require elevation?Yeah, it's the admin requirement/security risks. Junctions I think will be locked if any processes within the directory are running, which means that updating it would fail frequently.
As I've said above, the intended way to make a runtime "active" is to activate a venv. We went through the discussion process some years ago about not relying on this, and everyone involved wanted it this way, so it's what we have. Anyone who installs something with commands without adding the particular install path to their PATH will get a message from pip telling them what path to add, which leaves only pip itself, which has recommended
py -m pipfor years already.I expect I'll eventually get the entry points work working, hopefully without hurting install/refresh performance too much, and we'll be able to see how much that changes things. But there's only one case right now that's entirely uncovered, which is pip itself.
- added a commit that references this issue
on Dec 9, 2025 - marked Running
pipdirectly from CMD? #237 as a duplicate of this issueon Dec 11, 2025 I wonder if we just want messages about this from pymanager and commands to add/remove the installation directory of one of the installed runtimes to the
PATH. This is for the time being until/when pymanager might decide to extend pip or something so it also creates shim in the global shortcuts directory of pymanager.Agreed. Specifically, if the install manager has the authority and capability to change where the
pythoncommand points to, then every time that changes it should make it as easy as possible for the user to switchscriptsand similar hangers-on to the old python. Ideally, of course, this would be automated - is it possible for the program to modify path itself? or open a prompt for the user to do so?To that end, why aren't symlinks in the cards? since there's a single python file which is managed by the installer to point at the proper executable, a single folder would also be great. I know it's more complicated to point to something dynamic but it really feels like the solution
Reacted by FrankFAN and Hugo- marked This doesn't install pip or uv to my path, which makes it useless for my purposes #222 as a duplicate of this issue
on Jan 14, 2026 - added 2 commits that reference this issue
on Jan 15, 2026 I suggest automatically adding the
Scriptsdirectory of the default Python runtime toPATH, similar to what the standalone installer does.This would provide a more familiar and user-friendly experience, especially for new users who may not know how to configure
PATHmanually. With Python 3.16 and later, new users will have to use the Python Install Manager, so I think the user experience for newcomers should be given even more consideration.At the same time, users who understand how
PATHworks would still be able to manage it themselves.I don't think this would introduce significant environment conflicts, because only the
Scriptsdirectory of the current default Python runtime would be added. Whenever the default Python version changes, the newScriptsdirectory could be added with higher priority than the existing entries. This means that even if the previousScriptsdirectories are not removed, the one corresponding to the current default Python would always take precedence.This would also be consistent with the behavior of the legacy standalone installer. While automatically adding the
Scriptsdirectory toPATHmay not be a better solution in every respect, I don't think it would put users in a worse situation either. Since this behavior already existed in the standalone installer and provided a familiar out-of-the-box experience, I believe it would be reasonable to restore it in the Python Install Manager.It's a great suggestion, but it's also not viable, manageable, or safe. As soon as you have multiple installed runtimes, you'll have conflicts, and we're not able to manage those reliably from a program that is not a full GUI editor for the environment variable. It's absolutely a worse situation for everyone except those who want to manage PATH themselves (plenty of people know how and still don't want to, and they also suffer from randomly shifting alias resolution).
Adding a global scripts path is unfortunately one of those designs that turned out to be a mistake, and we're doing the best we can to stop making that mistake. The previous installers copied it from earlier versions, but we made the decision to stop it this time around.
Creating and activating a virtual environment is the recommended way to get a runtime-specific
Scriptsdirectory on PATH. Alternatively, using a single global directory with properly ordered scripts (such as was introduced with the PR attached to this issue) is also possible.Adding a bunch of semi-randomly ordered paths into a user configurable OS setting is not a good answer.
Reacted by op200
Currently after installation, the pip command is not available on the command line.
Having the option while installing to include the scripts directory as part of the path, or some other method which includes pip, would be useful to avoid having to to it manually.