[Distutils] Improving distutils' script and GUI app handling
theller at python.net
Thu Sep 15 19:54:59 CEST 2005
Trent Mick <trentm at ActiveState.com> writes:
> I haven't yet played with setuptools/eggs/etc. so my comments might be
> [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:
>> 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
More information about the Distutils-SIG