On 6/5/05, Ian Bicking
I agree that Windows scripts are messy and poorly understood. I for one don't have any opinion or knowledge about how to make a well-behaved Windows script...
I do :-) Or at least, I think I do... :-)
... however, I know how to make a good script on Unix and Mac machines, and I'm hardly going to give that up for Windows.
But if you make your code work via -m, then at least you haven't left us poor Windows users without any driver script at all!
I'd have a hard time replacing:
paster serve
with:
python -m execpackage paste.app_setup serve
Or even:
/path/to/svn/checkout/scripts/paster serve
With:
PYTHONPATH=/path/to/svn/checkout python -m execpackage paste.app_setup serve
And I don't even know how to do that on Windows.
So, right now the status quo is perfectly fine on Unixy machines, and we can't make that worse.
I didn't intend for one moment to suggest that we should. But I do feel, quite strongly, that it's platform-specific. People keep trying to make wrapper scripts "just work" cross-platform, and that's what I see as the mistake. OTOH, python -m execpackage paste.app_setup serve *can* be cross-platform. So writing a Unix wrapper round that, and a different Windows-specific wrapper, etc, is not an unreasonable approach. (Nor is writing a more capable Unix-specific implementation). Why do you need your "paster" script to be more complex than #!/bin/sh exec python -m execpackage paste.app_setup $* (excuse my pidgin Unix - assume I knew enough to write this properly :-))? What *I* am trying to move away from is having non-trivial cross-platform code in .py files installed as scripts. An example is with Twisted, twistd.py is installed as a script, but it has some non-trivial platform detection logic in it. It wouldn't take much to move that logic to the twisted.scripts.twistd module (or somewhere similar) so the twistd daemon could be run directly from a python -m invocation. Keep a trivial wrapper by all means, but don't make the wrapper the only way of getting the functionality.
I don't see why this should be so difficult to come to consensus on. So far consensus hasn't been very useful, because consensus would just turn into ad hoc scripts and installation processes. Recipes can't build consensus; but setuptools is actual code, not a recipe. And how strongly can people feel about .bat vs. .py vs. .exe? These aren't interesting enough problems to deserve fanaticism ;)
Welcome to Windows :-) Seriously, some issues: 1. .exe is binary, so not customisable. Also, you need two versions of any wrapper exe, one a console app and one a GUI one. But this is not a bad option. Fredrik Lundh has implemented something along these likes (exemaker). It's not a popular option though - maybe because the binaries must be built on Windows, maybe because of virus concerns, I don't know. 2. The default Python installer doesn't do all of the necessary magicto make .py files "executable". That's a deliberate policy decision, and not likely to change. It's my preference, though (I make the necessary changes manually). 3. .bat files are mildly, but annoyingly, non-cross-platform. As Windows 9x and command.com die, this is becoming less of an issue, but it's still there. Also, if you hit Ctrl-C to interrupt a .bat wrapper, the OS generates a horribly unfriendly "Abort batch job (Yes/No/Cancel)?" prompt. Oh, and there is no way to use .bat files to create a GUI wrapper - you *always* get a console window. As I say, my preference is (2), and I can argue that it's the only good one. But it ain't going to happen, so we're left with irritating workarounds. As long as I can get all I need by just ignoring the Python scripts directory, that's fine - but while some scripts include nontrivial logic, I can't do that. Paul.