[Distutils] Improving distutils' script and GUI app handling

[Thomas Heller]

Trent Mick <trentm at 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