[Python-Dev] PEP 370 - per-user scripts directory on Windows (original) (raw)

Steve Dower Steve.Dower at microsoft.com
Tue Feb 10 22:09:30 CET 2015

Paul Moore wrote:

On 10 February 2015 at 20:50, Paul Moore <p.f.moore at gmail.com> wrote:

On 10 February 2015 at 17:45, Steve Dower <Steve.Dower at microsoft.com> wrote:

This is yet another attempt to try and change user behaviour, which I'm not thrilled about, but I'm really starting to feel that this is the best way out of a bad situation. It differs from the solutions used on Linux, though there may be some value in this approach there too. Thought/votes/suggestions?

I have to admit, I agree with you. But before the "Add Python to PATH" option was added to the installer, we repeatedly got requests for it and it was apparently a constant source of confusion for beginners. If we're going to revert that change, we'll need to be very careful how we present it. Drat - hit "Send" too soon. Also, the proposed scripts won't be on PATH, so users will have to run them using explicit paths, which is both inconvenient and poses a discoverability issue (Tools/scripts/winadd2path.py has been round for ages, but AFAIK hardly anyone uses it). I wonder if there's a way to get the launcher (py.exe) to help? For powershell, we could have "py --setpath" write the appropriate path setting command to stdout, and users could use "Invoke-Expression $(py --setpath)", for example. That's a bit clumsy, and doesn't work for cmd.exe, but maybe there's possibilities... Essentially, py.exe is the only command guaranteed to be on PATH for any install (or is it? for a user install, is it stuck somewhere in the user's APPDATA?)

(For a user install, I've guaranteed that the launcher will be added to the user's PATH. But a system-wide launcher will win.)

win_add2path.py does the same thing as the installer, so it isn't a useful solution.

The py --setpath is basically my idea with activate-py, though with the "Invoke-Expression" part handled in the script (and not actually using Invoke-Expression, but that's implementation details). If these are part of the launcher, then they'll always be on PATH, and if they're just thin wrappers around py.exe then they can support all the same versions of Python (in effect, all of them, though with the 32/64-bit per-user collisions that existed pre-3.5).

It's fair enough to say that installers shouldn't be in the business of messing with PATH, but nevertheless, people expect to run an installer and have the installed programs available for use. Command line utilities like Mercurial do it, so people will expect Python to. Unfortunately.

And Python does, as long as that installed program is "py". The problem is that people expect "python" to be there and be the correct one (for a totally arbitrary definition of "correct") as well as pip, easy_install and anything installed by those two tools, whether they were installed for all users or just the current one. It's far more complex than a single app (especially when you realise that a system-wide install is effectively trying to make Python look like part of the OS - we only get that about 50% right now...).

Sorry, all problems, no real answers here. Paul

Yeah, same. activate-py is the best I've got.

Cheers, Steve

More information about the Python-Dev mailing list