On 9 March 2015 at 16:35, Donald Stufft <donald@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@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