Include pip in path

[KevinBrogan]

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.

[zooba]

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 pip to 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 its Scripts directory on PATH for 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 PATH isn't it.

[ykqmain]

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.

[pfmoore]

py -m pip should invoke pip. Does it not?

[ykqmain]

py -m pip should invoke pip. Does it not?

This command should be permanently displayed on the Usage page and consider adding an Alias, like this Issue #140

[zooba]

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?

[kaecy]

You can perform an upgrade if there is one python -m pip install --upgrade pip or install enable-pip python -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.

[akrymskiy]

Ironically 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.

[zooba]

We 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 --refresh command 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 have Scripts on PATH for your session.

[pfmoore]

I don't think it's reasonable to tie pip (and every other installation tool that might exist) to the pymanager command 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 python command 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 the Scripts directory will be available as well. We can blame OS limitations as much as we like, but the reality is that users who add python to 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 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? Or maybe pymanager install could print a reminder that the new installation's Scripts directory isn't on PATH by default, and describe how to add it if the user wishes to?

[zooba]

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 Scripts directory (there's none built into the CPython packages, since it would only include a broken pip.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 --refresh if the installers are not going to run it for them.