[Distutils] EasyInstall: scripts

[Paul Moore]

On 6/5/05, Ian Bicking <ianb at colorstudy.com> wrote:
> I agree that Windows scripts are messy and poorly understood.  I for one
> don't have any opinion or knowledge about how to make a well-behaved
> Windows script...

I do :-) Or at least, I think I do... :-)

> ... however, I know how to make a good script on Unix and Mac machines,
> and I'm hardly going to give that up for Windows.

But if you make your code work via -m, then at least you haven't left
us poor Windows users without any driver script at all!

>  I'd have a hard time replacing:
> 
>    paster serve
> 
> with:
> 
>    python -m execpackage paste.app_setup serve
> 
> Or even:
> 
>    /path/to/svn/checkout/scripts/paster serve
> 
> With:
> 
>    PYTHONPATH=/path/to/svn/checkout python -m execpackage
> paste.app_setup serve
> 
> And I don't even know how to do that on Windows.
> 
> So, right now the status quo is perfectly fine on Unixy machines, and we
> can't make that worse.

I didn't intend for one moment to suggest that we should. But I do
feel, quite strongly, that it's platform-specific. People keep trying
to make wrapper scripts "just work" cross-platform, and that's what I
see as the mistake.

OTOH, 

    python -m execpackage paste.app_setup serve

*can* be cross-platform. So writing a Unix wrapper round that, and a
different Windows-specific wrapper, etc, is not an unreasonable
approach. (Nor is writing a more capable Unix-specific
implementation).

Why do you need your "paster" script to be more complex than

    #!/bin/sh
    exec python -m execpackage paste.app_setup $*

(excuse my pidgin Unix - assume I knew enough to write this properly :-))?

What *I* am trying to move away from is having non-trivial
cross-platform code in .py files installed as scripts. An example is
with Twisted, twistd.py is installed as a script, but it has some
non-trivial platform detection logic in it. It wouldn't take much to
move that logic to the twisted.scripts.twistd module (or somewhere
similar) so the twistd daemon could be run directly from a python -m
invocation. Keep a trivial wrapper by all means, but don't make the
wrapper the only way of getting the functionality.

> I don't see why this should be so difficult to come to consensus on.  So
> far consensus hasn't been very useful, because consensus would just turn
> into ad hoc scripts and installation processes.  Recipes can't build
> consensus; but setuptools is actual code, not a recipe.  And how
> strongly can people feel about .bat vs. .py vs. .exe?  These aren't
> interesting enough problems to deserve fanaticism ;)

Welcome to Windows :-)

Seriously, some issues:

1. .exe is binary, so not customisable. Also, you need two versions of
any wrapper exe, one a console app and one a GUI one. But this is not
a bad option. Fredrik Lundh has implemented something along these
likes (exemaker). It's not a popular option though - maybe because the
binaries must be built on Windows, maybe because of virus concerns, I
don't know.

2. The default Python installer doesn't do all of the necessary
magicto make .py files "executable". That's a deliberate policy
decision, and not likely to change. It's my preference, though (I make
the necessary changes manually).

3. .bat files are mildly, but annoyingly, non-cross-platform. As
Windows 9x and command.com die, this is becoming less of an issue, but
it's still there. Also, if you hit Ctrl-C to interrupt a .bat wrapper,
the OS generates a horribly unfriendly "Abort batch job
(Yes/No/Cancel)?" prompt. Oh, and there is no way to use .bat files to
create a GUI wrapper - you *always* get a console window.

As I say, my preference is (2), and I can argue that it's the only
good one. But it ain't going to happen, so we're left with irritating
workarounds.

As long as I can get all I need by just ignoring the Python scripts
directory, that's fine - but while some scripts include nontrivial
logic, I can't do that.

Paul.