[Distutils] More Windows questions

[Phillip J. Eby]

Okay, I've looked at the registry a bit, and it seems like I can register 
App Paths either under HKLM (for the whole machine) or under HKCU (for the 
current user).  However, both seem to have issues.

Under later versions of Windows, especially when not running with 
administrative privileges, the HKLM keys will probably be off limits, and 
might generate warning popups of various kinds.  On the other hand, HKCU 
might not be that useful for a system-wide Python installation, and would 
seem to force you to repeatedly reinstall for each user.

I could ask the user, but they're not really any more likely to know what 
to do either, and in any case I'm thinking that for 0.6 I'd prefer to keep 
the installation code as simple as possible.  (Which means I don't want to 
even bother with a dialog, and will therefore just skip the .egg 
registration idea.)

Examining this a little further, I notice that there are a couple of 
problems with setuptools generating bdist_wininst installers right now:

1. The "-script.py" files don't get their #! lines updated, so if the 
destination machine has Python in a different location than on the 
generating machine, the wrapper .exe's won't work.

2. If you generate a bdist_wininst on a non-Windows platform, you don't get 
the "-script.py" and ".exe" wrappers to begin with.

So, here's what I'm thinking I should do.

First, setuptools' bdist_wininst should always generate -script.py and .exe 
wrappers, so that you can build correctly on non-Windows platforms.

Second, setuptools' bdist_wininst should add its own postinstall script that:

1. Updates the #! lines in the installed scripts to point to the right 
executable

2. Register HKCU "App Paths" entries for all console scripts, pointing to a 
second '-conio-.exe' wrapper for the same '-script.py', thus allowing 
console scripts to be run from the "Start/Run" command line.

(Note that easy_install could and maybe should do the same when run on 
Windows, but could have a command-line option to disable it, like 
--no-register or something.)

The net result would be that on Windows, the command-line would become at 
least somewhat useful.  If you are already in a command shell, "start foo 
args" will run the console script in a new window, without needing you to 
modify PATH or the default installation location(s).  This isn't perfect, 
but as an "out of the box" usability experience for the Windows command 
line, it would beat the heck out of what we have now.

Any thoughts?