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