On 5/30/05, Ian Bicking <ianb@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'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). 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. 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? Paul.