Trent Mick trentm@ActiveState.com writes:
I haven't yet played with setuptools/eggs/etc. so my comments might be ignorant.
[Phillip J. Eby wrote]
Then EasyInstall could create a 'unittest' script with a #! line on Unix-like OSes, and a 'unittest.py', 'unittest.bat', or 'unittest.exe' on Windows. In each case, the generated program would simply load and run the entry point with no arguments.
Effbot has some good things to say about/use for this: http://effbot.org/zone/exemaker.htm
On Windows, I'd say that applications are pretty much always better as .exe's, whether console or GUI. The .py/.pyw form is dependent on a single global consistent version of Python, but it's possible and reasonable to have multiple Python versions installed. An .exe also has a lot more control over how Python is initialized, and that can be particularly important for applications. On the other hand, in the short run I can also see using .bat or .cmd files for console apps, and .pyw for GUI apps, just to have something that works and wait for the path management use cases for various .exe options to work themselves out.
Which path management? Do you mean the default distutils build directory (which we discussed some time ago)?
There is a bug in the current cmd.exe (or maybe it is only up to Win2k? can't remember) where shell redirection doesn't work if your script is launched indirectly via a .bat of .cmd file. As well, Ctrl+C signal handling for kill a script is quite annoying if launched via a .bat file: you get a secondary question from the shell
Terminate batch file (Y/N)?or something like that. A .exe launcher/stub is definitely preferred.
Isn't the shell redirection problem also present if the .py script is run via the shell association?
The Ctrl+C behaviour annoys me also because I usually run my scripts via batch files (py23.bat, py24.bat, py_d.bat and so on). Maybe this problem can be avoided by copying the python.exe's somewhere to my path, with names p23.exe, p24.exe and so on. They only contain a pointer to the actual PythonXY.dll name, afaik. So I don't have to update p24.exe when I install 2.4.2 over my 2.4.1.
Somewhat similar to the exemaker approach, but using the name of the exe to specify the Python version instead of a '-i ...' command line option, or the #! line in the script.
The only missing piece so far, for me at least, is that it's not possible to use dotted module names with the -m option:
p24 -m ctypes.wrap.h2xml windows.h
Thomas