[Distutils] Improving distutils' script and GUI app handling

[Trent Mick]

[Trent]
> > In any case, I'd say it is extremely *common* for Windows users to put
> > the Python install dir on their PATH -- just as it is common for Windows
> > Perl and Ruby users to put the interpreter dir on their PATH. I'd then
> > say that the obvious place to put user scripts installed via distutils
> > is that same directory.

[Thomas Heller wrote]
> Well, I don't think so.  It *may* be common for windows users who use
> the command line ;-), but I would guess that's a minority anyway.

A minority of Windows users of Python use the command line? Really?
Anyone coming from Unix will immediately go there. Last I remember
"Learning Python" and the Python tutorial and other intro texts
encourage the user to open the interactive shell at the command line to
play around. You may be right, though. Even if it is "a minority" I
suspect that is still a big number.

Even for that set of Windows users that *do* use the command line, having
Python get on their PATH automatically just makes sense:

It allows other systems that depend on Python to be able to just work
after an installation. For example, the Mozilla build system on Windows
requires an installation of Perl. The build instructions can just say
"install ActivePerl" (which puts Perl on the user's PATH) and thereafter
the build system can easily find the Perl is needs. I bet that systems
out there requiring Python have more difficulty.

It allows tutorials/introductory-texts to have a lowest common
denominator that just works for newbies on all platforms:
    1. install Python
    2. type "python script.py"
Then they can get on to all the subtle platform-specific bells and
whistles, viz:

> Even though I *use* the command line, I've never put python.exe on my
> PATH.  It's easier to type 'myscript' or 'myscript.py' than 'python
> myscript.py' anyway. 

That is presuming that the Windows installer set up a .py file
association and put .py;.pyc;... in the PATHEXT env. var.


Does putting an installed Python on the PATH cause damage in any way?


> Then, I have multiple versions installed on my
> machine, and to select between 2.3.5, 2.4.1, and the CVS version I can
> always use 'py23 myscript.py', 'py24 myscript.py', 'py myscript.py' and
> 'py_d myscript.py' - the latter to run it with the debug compiled CVS
> version.  I had created batchfiles py23.bat and so on which specify the
> directory of the python.exe or python_d.exe files.

A week or so ago I asked you what you thought of the idea of having the
Windows build (and installers) have a "pythonXY.exe" or "pythonX.Y.exe"
along with the usual "python.exe". This would match what is done on
other platforms to allow multiple versions on Python on the PATH and
still be able pick a specific one. (I'm not sure if you replied.) I do
something similar to your "py23", "py24", ... thing. A common mechanism
for this would be nice.


> And this also explains why I'm still waiting for the extented version of
> the '-m' command line option and did not bother to put the
> PythonXY\Scripts directory on the PATH - I would loose the ability to
> easily switch versions.

And gain a subtle python-specific way to launch a script.


I realize I am ranting above, but I just think it is crazy to have the
situation these days where, for example, I download and install
pychecker and then try to run it:

    C:\trentm\tmp>pychecker
    'pychecker' is not recognized as an internal or external command,
    operable program or batch file.

I understand your wanting a mechanism to easily be able to run any
Python scripts/modules you have with any Python installation/build you
have, but the common user case is just:
(1) I have my latest Python installation,
(2) I want to run something installed with "python setup.py install"


Trent

-- 
Trent Mick
TrentM at ActiveState.com