[Distutils] Improving distutils' script and GUI app handling

[Ian Bicking]

Phillip J. Eby wrote:
> Every so often, there's a perennial debate on the distutils-sig about 
> script filenames.  Should they have .py extensions or not?  What about .pyw 
> apps on Windows?  What about Mac OS?  and so on.
> 
> It occurred to me this morning that we now have a new tool for resolving 
> this issue in setuptools' "entry points" feature.  For various reasons, 
> it's common practice to write scripts as Python modules with a "main" 
> function of some kind.  These modules are then run directly with '-m', or 
> use "if __name__=='__main__'", or have a short script that imports the main 
> function and runs it.

I've already noted my distaste for __name__ == '__main__', so I'd be 
happy to see it go (or, at least replaced with something better).  An 
entry point seems easy.

One issue that has come up for me is the way setuptools currently 
generates scripts causes problems for me.  For instance, if I do 
tag_svn_revision, then the version of my package can change in place 
(whenever I do setup.py egg_info).  The script has a version hardcoded 
in it, and so it fails.

I'm not sure what the best way to handle this is, but the current 
behavior can look very ugly from a user's perspective when it fails.  At 
least if I'm using tag_svn_revision, if I could put a requirement spec 
in setup.cfg to also control what the script requires, that would help. 
  Also, if we support multiple versions of packages, each with a script 
tied to that version, then there needs to be an easier way to control 
the script names, e.g., --script-suffix=0.4 or something.

The other issue is which Python version is used to load the script; it's 
not uncommon to want to switch versions.  It would be nice if there was 
something -- an option, perhaps, or an environmental variable -- which 
could override the Python version.  E.g. script 
--python-version=python2.4, or PYTHON_VERSION=python2.4 script (I don't 
think the later isn't reasonable to do in Windows, though)

> * What groups (if any) should exist besides "console_apps" and "gui_apps"?

I can't think of any, except of course for ad hoc subcommands like 
distutils.command.  Well, rc scripts and system services perhaps, but 
that's not something I'd want to tackle right now; it's not even clear 
that a package should map to an rc script.

> * Should launchers hardcode their sys.path?  This would prevent breakage 
> caused by installing new and incompatible versions of their dependencies, 
> but require an explicit upgrade action to update them, and make the 
> installation process more complex.

I'm wary of hardcoding paths.  I don't think we should completely 
embrace encapsulation -- it might be better for long-term stability 
(maybe), but it makes it harder to fix a system that is broken (even 
when "brkoen" just means one missing requirement).

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