[Python-Dev] Utility scripts (Was: '-m' option)

[Paul Moore]

The problem here is really one of packaging. How should utility
scripts be distributed, either with Python, or with extensions? There
are many different approaches:

1. a library module with useful behaviour in the __main__ block.
2. a script in sys.prefix + '/scripts' with no extension and a #! line
3. a script as above, but with a .py extension
4. a script as (2) plus a .bat wrapper for Windows
5. a script as (3) plus a .bat wrapper for Windows

However, *none* of these give the best behaviour, uniformly across all
Windows platforms (the Unix story is far better, as there is a
consistent and useful behaviour across all shells).

While case (1) is a bit of an anomaly, Guido's script would probably
cover it, *if* a really acceptable solution for scripts could be
found.

Accepting that Unix is generally not an issue, let's look at Windows.
On cmd.exe, at least on Windows 2000 and up, the following makes .py
files "executable" by python:

    assoc .py=Python.File
    ftype Python.File=C:\Python23\python.exe "%1" %*
    set PATHEXT=%PATHEXT%;.py

Can anyone test this on COMMAND.COM on Win9x? It works using the
COMMAND.COM supplied with Windows 2000, whatever that proves :-)

Of these, the first two are set by the standard Windows install. The
final one could be. With that change, simply putting a .py script into
C:\Python23\Scripts would be enough (assuming C:\Python23\Scripts was
on the user's PATH, which it isn't by default, but the user can add
it).

Proposal:

- Change the Windows Python binary to add .py (and .pyw, maybe) to PATHEXT
- Add a variation of Guido's script to the standard install, as
something like runmod.py
- Document that the way for extensions to include scripts is as .py
files in the sys.prefix+'/scripts' directory, with a #! line for Unix
- For Unix users who don't like extensions, suggest (again in the
docs) that a hardlink can be added without the extension. Maybe
include a suitable setup.py snippet to show how.
- Possibly add sys.path+'/scripts' to the PATH - I'm not sure about
this, as on Windows the installer seems to try hard to *not* modify
PATH, so maybe this is a policy issue.

I'm punting on the issue of python.exe flags. If someone wants to run
a supplied script as python -E -S -O script.py, I don't have a
solution (other than doing so "longhand"). But I don't have a use
case, either, so I'll leave that one for others...

Paul