Trent Mick <[EMAIL PROTECTED]> 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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig