[Distutils] EasyInstall: scripts

[Phillip J. Eby]

At 04:16 PM 6/5/2005 +0100, Paul Moore wrote:
>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


I like these ideas, but for the moment, I think we need to make existing 
packages' scripts work, or there's not going to be enough initial adoption.

My current plan is to simply tack an extra line between the #! line and the 
rest of the script, assuming it has either a .py extension or a #! line 
containing "python".  The line would read something like:

import pkg_resources; pkg_resources.require("OwningPackage==exactversion"); 
del pkg_resources

This would work as long as there were no 'from __future__' import lines in 
the script.  (Which we could check for, and move the line after, but I'm 
not sure I want to get that complicated, certainly not in the first version 
of the feature.)  The script would then be installed according to normal 
distutils practices in all other respects.

Of course, to support this, bdist_egg will need to add the scripts to an 
'EGG-INFO/scripts' subdirectory.  That way, you get them even when 
installing from an egg, and when you switch active library versions using 
EasyInstall, it can remove the old scripts and install the new ones.


>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'd definitely like to encourage people to do that, and build up assistive 
infrastructure for it.  But, EasyInstall has to have a strategy for dealing 
with today's scripts, or it's not very useful today.