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.