[Distutils] EasyInstall: scripts

[Paul Moore]

On 5/30/05, Ian Bicking <ianb at colorstudy.com> wrote:
> Phillip J. Eby wrote:
> > It might help if there were some kind of metadata for scripts, like to
> > indicate whether something is a command-line utility, a graphical
> > application, etc.  Then distutils could tweak the file extension and/or
> > build a custom launcher for it (like Fredrik Lundh's exemaker for
> > Windows) as appropriate for the platform.  That information could then
> > be added to EGG-INFO and/or EGG-SCRIPTS, and used by EasyInstall to do
> > script installation and uninstallation.
> 
> That's what I'd be inclined towards.  Like, this is what one script I
> have looks like:

Scripts are a *pain*, basically because so much of the peripheral
issues are OS-specific.

On Unix, the general preference seems to be a script with no
extension, and a #! line, written in Python, for most cases (Unix is
nice and uniform like that :-))

On Windows, the file extension determines executability. Opinion seems
divided (probably not evenly) between people who prefer a .py
extension (along with appropriate PATHEXT/file association magic,
which the default install does *not* do) and people who prefer a .bat
(or even .exe) wrapper. On Windows, GUI and console applications need
to be run with different Python executables, adding another level of
complexity.

I'd like to see the basic "wrap up a script" functionality tidied up -
leave start menu changes, shortcuts, aliases, PATH changes, etc etc,
as OS-specific enhancements. Experienced users can do this for
themselves, and packagers can write platform-specific "installer"
scripts where appropriate. (Personally, I dislike most installers'
choices for start menu items anyway :-))

The python -m option solves 90% of the script issue in my view. Simply
write your driver script as a Python module, and install it as such.
Then it can be invoked via python -m (or pythonw -m if it's a GUI
application).

Most of the remaining 10% would be covered by extending -m to
packages. There is a Cookbook recipe which demonstrates a module which
can do this (so we have "python -m execpackage my.package.script arg1
arg2...") but it would be nice if this were built in. This is mainly a
namespace issue, though.

For eggs, we're 90% of the way to executable eggs. All that's needed
is a way of adding a particular egg to sys.path, then using the -m
machinery (with a standard module name, such as main, or maybe
requiring the user to specify a module, effectively an egg
"subcommand", or possibly reading egg metadata). This could be
implemented as an egg.py module, so you'd have

    python -m egg path/to/my/sample.egg arg...

(invokes the main module, or one from egg metadata).

    python -m egg -m subcmd path/to/my/sample.egg arg...

(invokes the subcmd module - maybe -m for the subcmd option name isn't
an ideal choice...)

Of course, on Unix, this can be handled by temporary environment
variable setting, like

    PYTHONPATH=path/to/my/sample.egg python -m main arg...

but the point here is to make it cross-platform.

As I say, the command lines can look a bit clumsy, but wrapping that
up in an alias, or desktop shortcut, or whatever, is something I
explicitly defer to platform-specific installers.

You'll notice that I've completely sidestepped the idea that distutils
build "appropriate" wrappers or launchers, or tweak extensions. Past
experience has shown that it's incredibly hard to get any consensus on
this sort of thing. But it *is* possible (IMHO) to get 90% of the way
there, just by getting people to use -m compatible modules. Of course,
that isn't 2.3 compatible. But I'd rather move forward than keep
trying to work around the same issues - -m was added to address
something that people had tried, and failed, to solve in pure Python
2.3, so why reopen that again?

Paul.