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

[Paul Moore]

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

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)

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?

It feels to me like this might be a frustrating step backwards for
Windows users who have recently (with the arrival of ensurepip) got to
the point where they can just run Python with "Add to path" and then
simply do

pip install pygments
pygmentize --help

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 completely OK with the idea that we move to "Program Files" as a
default location. And I have no real issue with Steve's position that
the "Add to Path" option has issues that can't really be solved
because of the way Windows constructs the PATH. But I know there have
been a lot of people frustrated by the complicated instructions needed
to get something like pygmentize working, for whom getting pip in 2.7
and 3.4 was a major improvement. So I think we need *some*
documentation helping them deal with what could well seem like a step
backwards in Python 3.5...

If I knew what the best (recommended) answer was, I'd be happy to
write it up. But I'm not sure I do (after all, the target audience is
people for whom "Add C:\PythonXY\Scripts to your PATH" was a problem
in the pre-3.4 days).

Should I raise this as a bug against the 3.5 documentation? If so,
should it be a release blocker for the final release?

Paul
___
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

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

[Nick Coghlan]

On 9 March 2015 at 21:19, Paul Moore  wrote:
> Should I raise this as a bug against the 3.5 documentation? If so,
> should it be a release blocker for the final release?

I'm happy to let the folks that use Windows for development regularly
decide on the best answer from a user experience perspective, but I
think a release blocker docs issue would be a good way to go for
ensuring it gets resolved be the release goes out.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

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

[Paul Moore]

On 9 March 2015 at 13:45, Nick Coghlan  wrote:
> I'm happy to let the folks that use Windows for development regularly
> decide on the best answer from a user experience perspective, but I
> think a release blocker docs issue would be a good way to go for
> ensuring it gets resolved be the release goes out.

Done. http://bugs.python.org/issue23623
___
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

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

[Steve Dower]

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
___
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

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

[Donald Stufft]

> On Mar 9, 2015, at 11:37 AM, Steve Dower  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [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  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  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
___
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

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

[Nick Coghlan]

On 10 Mar 2015 02:37, "Donald Stufft"  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" 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
>
___
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

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

[Donald Stufft]

> On Mar 9, 2015, at 7:11 PM, Nick Coghlan  wrote:
> 
> 
> On 10 Mar 2015 02:37, "Donald Stufft"  > 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 " 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

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

[Paul Moore]

On 9 March 2015 at 23:11, Nick Coghlan  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
___
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

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

[Jim J. Jewett]

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
___
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