[Distutils] EasyInstall: scripts

[Ian Bicking]

Paul Moore wrote:
> 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 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'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).

... 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.  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.

> 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.

I would be fine with that too, but I think installers need to take up 
the cause before this will work.  And anyway, easy_install is an 
installer, so this is within its scope.  I think I'd like these semantics:

setup(...
     script_packages=[{'paster': 'paste.app_setup:main'}])

Then a script is generated by that name (with some extension on Windows, 
I don't care what), and it does:

   import paste.app_setup
   sys.exit(main(sys.argv) or 0)

Well... somewhere in there it would be nice to make the distinction 
between console and GUI applications, to make that script use pythonw on 
Windows.

One issue, though, is how to run the script differently.  For instance, 
how to use a different installation/version of Python, or how to best 
setup or change sys.path.  For instance, I always try to detect if the 
script is being run out of a checkout, and fix up the path when doing so 
(not only does this avoid PYTHONPATH setup, it means that you won't 
accidentally run a script with a perhaps older installed version of a 
package if you forget to fix PYTHONPATH).

> 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?

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 ;)

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org