Re: [Python-Dev] Thoughts on running Python 3.5 on Windows (path, pip install --user, etc)
Paul Moore wrote:
I just thought I'd give installing Python 3.5 a go on my PC, now that 3.5a2 has come out. I didn't get very far (see earlier message) but it prompted me to think about how I'd use it, and what habits I'd need to change.
I'd suggest that the "what's new in 3.5" document probably needs a section on the new installer that explains this stuff...
This is true. Right now I'm in experimentation mode, and being more aggressive about changing things than is probably a good idea (because it solicits feedback like this :) ). When things settle down I expect to end up closer to where we started, so there's not a huge amount of value in writing it all up right now. I'll get there.
First of all, I always use "all users" installs, so I have Python in "Program Files" now. As a result, doing "pip install foo" requires elevation. As that's a PITA, I probably need to switch to using "pip install --user". All that's fine, and from there "py -3.5" works fine, as does "py -3.5 -m foo". But even if it is, not every entry point has a corresponding "-m" invocation (pygments' pygmentize command doesn't seem to, for example)
I know you're already involved in this Paul, but for everyone else there's a big discussion going on at https://github.com/pypa/pip/issues/1668 about changing pip's default behaviour to handle falling back to --user automatically.
But suppose I want to put Python 3.5 on my PATH. The installer has an "add Python to PATH" checkbox, but (if I'm reading the WiX source right, I didn't select that on install) that doesn't add the user directory. So I need to add that to my PATH. Is that right? And of course, that means I need to *know* the user site directory ($env:LOCALAPPDATA\Python\Python35\Scripts), correct?
Correct. There's no way to add a per-user directory to PATH from an all-users installation (except for a few approaches that I expect/hope would trigger malware detectors...)
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...) Cheers, Steve
On Mar 9, 2015, at 11:37 AM, Steve Dower <Steve.Dower@microsoft.com> wrote:
Paul Moore wrote:
I just thought I'd give installing Python 3.5 a go on my PC, now that 3.5a2 has come out. I didn't get very far (see earlier message) but it prompted me to think about how I'd use it, and what habits I'd need to change.
I'd suggest that the "what's new in 3.5" document probably needs a section on the new installer that explains this stuff...
This is true. Right now I'm in experimentation mode, and being more aggressive about changing things than is probably a good idea (because it solicits feedback like this :) ). When things settle down I expect to end up closer to where we started, so there's not a huge amount of value in writing it all up right now. I'll get there.
First of all, I always use "all users" installs, so I have Python in "Program Files" now. As a result, doing "pip install foo" requires elevation. As that's a PITA, I probably need to switch to using "pip install --user". All that's fine, and from there "py -3.5" works fine, as does "py -3.5 -m foo". But even if it is, not every entry point has a corresponding "-m" invocation (pygments' pygmentize command doesn't seem to, for example)
I know you're already involved in this Paul, but for everyone else there's a big discussion going on at https://github.com/pypa/pip/issues/1668 about changing pip's default behaviour to handle falling back to --user automatically.
But suppose I want to put Python 3.5 on my PATH. The installer has an "add Python to PATH" checkbox, but (if I'm reading the WiX source right, I didn't select that on install) that doesn't add the user directory. So I need to add that to my PATH. Is that right? And of course, that means I need to *know* the user site directory ($env:LOCALAPPDATA\Python\Python35\Scripts), correct?
Correct. There's no way to add a per-user directory to PATH from an all-users installation (except for a few approaches that I expect/hope would trigger malware detectors...)
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…)
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 :) --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
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
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
On 10 Mar 2015 02:37, "Donald Stufft" <donald@stufft.io> wrote: 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). While I like the idea of offering something more "built in" in this space, my initial inclination is to prefer extending "-m" to accept the "module.name:function.name" format to let you invoke entry points by the name of the target function (Possible API name: runpy.run_cli_function), and then add a "runpy.call" that can be used to call an arbitrary function with positional and keyword string arguments based on sys.argv and (optionally?) print the repr of the result. It wouldn't be a universal panacea (and would need a PEP to work out the exact UX details), but would likely make quite a few libraries more command line accessible without needing to modify them. Cheers, Nick.
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 :)
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ 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/ncoghlan%40gmail.com
On Mar 9, 2015, at 7:11 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 10 Mar 2015 02:37, "Donald Stufft" <donald@stufft.io <mailto: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).
While I like the idea of offering something more "built in" in this space, my initial inclination is to prefer extending "-m" to accept the "module.name:function.name <http://unction.name/>" format to let you invoke entry points by the name of the target function (Possible API name: runpy.run_cli_function), and then add a "runpy.call" that can be used to call an arbitrary function with positional and keyword string arguments based on sys.argv and (optionally?) print the repr of the result.
It wouldn't be a universal panacea (and would need a PEP to work out the exact UX details), but would likely make quite a few libraries more command line accessible without needing to modify them.
If I understand this correctly, you’re suggesting that to run ``pygmentize`` without using the script wrapper, you’d need to do ``py -m pygments.cmdline:main`` instead of ``pygmentize``? I don’t think that actually solves the problem (except by making it so that the script wrappers can maybe just be exactly #!/usr/bin/python -m pygments.cmdline:main but that’s a different thing..). I’m not against it in general though, I just don’t know that it solves the problem Paul was mentioning. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 9 March 2015 at 23:11, Nick Coghlan <ncoghlan@gmail.com> wrote:
While I like the idea of offering something more "built in" in this space, my initial inclination is to prefer extending "-m" to accept the "module.name:function.name" format to let you invoke entry points by the name of the target function (Possible API name: runpy.run_cli_function), and then add a "runpy.call" that can be used to call an arbitrary function with positional and keyword string arguments based on sys.argv and (optionally?) print the repr of the result.
It wouldn't be a universal panacea (and would need a PEP to work out the exact UX details), but would likely make quite a few libraries more command line accessible without needing to modify them.
Personally I doubt it would make much difference. If the docs say "pygmentize" I'm unlikely to dig around to find that the incantation "python -m pygments.somemodule:main" does the same thing using 3 times as many characters. I'd just add Python to my PATH and say stuff it. Paul
On 10 March 2015 at slightly after midnight. Paul Moore wrote:
Personally I doubt it would make much difference. If the docs say "pygmentize" I'm unlikely to dig around to find that the incantation "python -m pygments.somemodule:main" does the same thing using 3 times as many characters. I'd just add Python to my PATH and say stuff it.
There is value in getting the incantation down to a single (preferably short) line, because then it can be used as a shortcut. That means it can be created as a shortcut at installation time, and that someone writing their own batch file can just cut and paste from the shortcut properties' target. Not as simple as just adding to the path, but simpler than adding several directories to the path, or modifying other environment variables, or fighting an existing but conflicting python installation already on the path. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ
participants (5)
-
Donald Stufft -
Jim J. Jewett -
Nick Coghlan -
Paul Moore -
Steve Dower