Paul Moore wrote: > On 10 February 2015 at 20:50, Paul Moore <p.f.mo...@gmail.com> wrote: >> On 10 February 2015 at 17:45, Steve Dower <steve.do...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
