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? _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig