[Python-Dev] Python install layout and the PATH on win32

[Paul Moore]

On 20 March 2012 14:27, VanL <van.lindberg at gmail.com> wrote:
> Germane to this discussion, I reached out for feedback. Most people didn't
> care about the issue, or were slightly inclined to have it be uniform across
> platforms.
>
> As Terry mentioned, I think that long-term uniformity will benefit everybody
> down the line, and that is the way to go.
>
> The most interesting feedback, though, related to moving the Python exe and
> placing it on the PATH. I got one argument back that I thought was
> persuasive here: We want things to 'just work.' Specifically, the following
> sequence of events should not require any fiddling on Windows:
>
> 1. Install python.
> 2. Open up a shell and run "python"
> 3. Use pip or easy_install to install regetron (a package that installs an
> executable file).
> 4. Run regetron.
>
> For step #2, the python exe needs to be on the PATH. For steps 3 and 4, the
> binaries directory needs to be on the PATH.

This is covered (better, IMO) by PEP 397 - Python Launcher for Windows.

Step 2, just run "py". If you prefer a particular version, run "py -2"
or "py -3" or "py -3.2".

Adding python.exe to PATH actually makes this message *worse* as it
confuses the issue. In a post-PEP 397 world, I would say that we
should be telling Windows users *not* to run python.exe at all.
(Unless they are using virtualenvs - maybe PEP 397 could do with an
extra option to run the Python from the currently active virtualenv,
but that's a side issue).

If we do put python.exe on PATH (whether it's in bin or not), we have
to debate how to handle people having multiple versions of python on
their machine. In a post-PEP 397 world, no Python is "the machine
default" - .py files are associated with py.exe, not python.exe, so we
have to consider the following 3 commands being run from a shell
prompt:

    1. myprog.py
    2. py myprog.py
    3. python myprog.py

1 and 2 will always do the same thing. However, 3 could easily do
something completely different, if the Python in the #! line differs
from the one found on PATH. To me, this implies that it's better for
(3) to need explicit user action (setting PATH) if it's to do anything
other than give an error. But maybe that's just me. I've been hit too
often by confusion caused by *not* remembering this fact.

Note: I am using Vinay's py.exe all the time these days, so my
comments about a "post-PEP 397 world" are from my direct experience.

For your steps 3 and 4, there is certainly user intervention required
as things stand. It would indeed be nice if "regetron" just worked as
expected. But I'd argue a few points here:

1. On Windows, if regetron was not explicitly an application for
working with my Python installation (like pip, easy_install, nose,
etc) then I'd prefer it to be packaged as a standalone application
using cx_Freeze or py2exe. I've had too many "applications" break
because I accidentally uninstalled a dependency from my Python
installation to want anything that is an end-user application
installed into my Python scripts/bin directory.

2. If regetron is not an end-user application, it should really be
getting installed in, and run from, a virtualenv. And in that case,
activating the right virtualenv is part of the workflow. And that sets
up PATH as needed, so there's no problem here.

The problem with your example is that it depends on the
package/executable. I looked at regetron (I thought it was a made up
example at first!) and it seems clear to me that it should either be
packaged up with py2exe/cx_Freeze, or (if it's sufficiently
version-independent) sit outside of Python's installation tree. I
can't see any reason why I'd expect a "regetron" command to work or
not depending on which copy of Python on my PC I have active. But
other applications may differ, I guess.

I concede that the picture is much simpler when people only ever have
a single version of Python on their machine. So for that case alone,
maybe the "Make this Python the default" option in the installer
should add the bin directory (or Scripts and the root, under the
current layout) to the PATH. But equally, if the installer detects
another copy of Python already installed, it should probably warn the
user loudly that it's important to understand the implications of
setting "make this Python the default", and should not set it by
default (this may be the current behaviour, I don't know).

I have no idea what proportion of Python users on Windows have
multiple versions installed. I also have no idea how many such users
work on the command line. My guess would be "not that many" and "not
that many of the first group" respectively... But there are big groups
like scientists and web developers who could sway these figures a lot.

> In hearing from a couple people who teach python to beginners, this is a
> substantial hurdle - the first thing they need to do is to edit their
> environment to add these directories to the PATH.

I'd be curious as to how much PEP 397's py.exe would have helped those
people. But yes, it's an issue. Although someone at some point will
have to introduce those beginners to the question of Python 2 vs
Python 3, and PATH pain will hit them then, anyway.

> This is orthogonal to the Scripts/bin issue, but I thought it should be
> brought up.

Agreed (both that it's orthogonal and that it should be discussed).
Once Python 2 is dead and gone, these issues will be a lot simpler -
but I don't think that's going to be for a few years yet.

Paul.