[Python-Dev] PEP 370 - per-user scripts directory on Windows

[Steve Dower]

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/win_add2path.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