[Distutils] Improving distutils' script and GUI app handling
ianb at colorstudy.com
Thu Sep 15 17:41:39 CEST 2005
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
More information about the Distutils-SIG