[Python-Dev] Thoughts on running Python 3.5 on Windows (path, pip install --user, etc)

[Paul Moore]

On 9 March 2015 at 16:35, Donald Stufft <donald at stufft.io> wrote:
>> I'm okay with this. Installing for all users is really something that could be considered an advanced option rather than the default, especially since the aim (AIUI) of the all-users install is to pretend that Python was shipped with the OS. (I'd kind of like to take that further by splitting things more sensibly between Program Files, Common Files and System32, but there's very little gain from that and much MUCH pain as long as people are still expecting C:\PythonXY installs…)
>
> Maybe the answer is to write up a PEP and standardize the idea of entry points, specifically the console_scripts and ui_scripts (or whatever it’s called) entrypoints and then give Python something like -m, but which executes a specific entry point name instead of a module name (or maybe -m can fall back to looking at entry points? I don’t know).
>
> I’ve given this like… 30s worth of thought, but maybe:
>
>     pip install pygmentize  # Implicit —user
>     py -e pygmetize
>
> Is an OK UX for people to have without needing to add the user site bin directory to their PATH. Maybe it’s a horrible idea and we should all forget I mentioned it :)

That would be good. You can do it now using setuptools' entry point
API, so making it part of the core is certainly not impossible. But is
it practical on the 3.5 release timescales? It's worth taking into
account the fact that pygmentize is exposed by pygments, so there's no
way to deduce the package from the entry point name. Also, even if a
core feature appears, nobody will be using it for ages.

On 9 March 2015 at 15:37, Steve Dower <Steve.Dower at microsoft.com> wrote:
>> Maybe the answer is that we simply start recommending that everyone on Windows
>> uses per-user installs. It makes little difference to me (beyond the fact that
>> when I want to look at the source of something in the stdlib, the location of
>> the file is a lot harder to remember than C:\Apps\Python34\Lib\whatever.py) but
>> I doubt it's what most people will expect.
>
> I'm okay with this. Installing for all users is really something that could be considered an advanced option rather than the default, especially since the aim (AIUI) of the all-users install is to pretend that Python was shipped with the OS. (I'd kind of like to take that further by splitting things more sensibly between Program Files, Common Files and System32, but there's very little gain from that and much MUCH pain as long as people are still expecting C:\PythonXY installs...)

Just to be clear, I'm *not* okay with this in the form I proposed it.
I think we're a long way yet from a clean and understandable proposal
for having user installs be as usable as system installs. It's worth
noting that (as far as I know) users don't typically use user installs
even on Unix, where the issue of the system install being read-only
has always been the norm. To me, that implies that there are still
some pieces of the puzzle to be addressed.

And again, I don't know if this is going to be solved in Python 3.5
timescales. Beta 1 is May 24th - would a major change like a version
of pip defaulting to user installs be acceptable after that? More
specifically, would core changes to install processes and recommended
practices to support that be allowed after the beta?

Maybe I'm being pessimistic. A good solution would be fantastic. But
at the moment, I feel like 3.4 (and 2.7.9) with pip and the scripts
directory on PATH was a huge usability step forward for naive users on
Windows, and we're in danger here of reverting it. And getting "naive
user" feedback until after the release is notoriously hard... A
"practicality beats purity" solution of sticking to the old install
scheme for one more version seems like it should be left as an option,
at least as a fallback if we don't solve the issues in time.

Paul