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?
On Tue, Oct 03, 2006 at 08:10:49PM -0400, Phillip J. Eby wrote:
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
I have seen a number of installers that phrase it as a radio group like "Install for: [] all users [] just me.". You can probably detect whether the user has admin rights and not ask if they don't have permission for the initial install of setuptools. Eggs installed with easy_install can know how easy install was installed and follow that setting if the user doing the install is the same or has equivalent rights.
I think there are 3 scenarios on Windows that are likely: 1. The installing user is always a privileged user, and the only user of the computer so either HKLM and HKCU will work 2. The installing user is unprivileged and therefore not expecting to install for everyone, so HKCU will do the trick. 3. The installing user is the administrator who expects the installation to work for all users and so needs HKLM to work. Presumably this user knows something about Windows (not necessarily so for the first two users) but is far less likely to know anything about windows (i.e. is installing for user #2 and doesn't know anything about this Python crap, he just wants user #2 to stop bugging him about installing program/library/package x).
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.)
If you (can) detect permissions doing what you can with those permission will probably "just work". I don't know how you go about figuring out what permissions the current user has. You might need ctypes or win32all or a C extension to figure out what permissions a user has.
On the download side, is there a way to force the download to go through the windows APIs that perform the proxy authentication? I think the Cygwin installer does something like that. I always used http://ntlmaps.sourceforge.net/ which is written in python and licensed under GPL. Maybe that can be used, unless I misunderstand the download issue.
-Chris
At 12:15 AM 10/4/2006 -0400, Chris Lambacher wrote:
You might need ctypes or win32all or a C extension to figure out what permissions a user has.
Well, I suppose I could just try modifying the registry. :) The big question is whether that causes a bunch of warnings to pop up, or triggers antivirus programs. Any thoughts?
On the download side, is there a way to force the download to go through the windows APIs that perform the proxy authentication? I think the Cygwin installer does something like that. I always used http://ntlmaps.sourceforge.net/ which is written in python and licensed under GPL.
...which effectively makes it incompatible with setuptools' licensing.
Maybe that can be used, unless I misunderstand the download issue.
The issue is that you still have to tell MAPS where to find the proxy settings, as well as the authentication info to use, even if you run it.
However, if someone wants to create a way to run a MAPS plugin for setuptools, I'll add entry point support so that it can be plugged in independently. That way, somebody can make a plugin egg that uses MAPS to provide proxy support, and *that* library would have to be GPL, but setuptools would not because it's just providing a generic customization hook for installed programs to be told when setuptools is about to do network access.
One could possibly even write some crazy plugin that actually used IE via COM to do the same thing, come to think of it, or to provide a GUI interface for downloading. :)
On Wed, Oct 04, 2006 at 12:12:32AM -0400, Phillip J. Eby wrote:
At 12:15 AM 10/4/2006 -0400, Chris Lambacher wrote:
You might need ctypes or win32all or a C extension to figure out what permissions a user has.
Well, I suppose I could just try modifying the registry. :) The big question is whether that causes a bunch of warnings to pop up, or triggers antivirus programs. Any thoughts?
It looks like _winreg raises an exception if the process does not have sufficient privileges. On vanilla XP I expect that is all that happens. Who knows what kind of wacky things 3rd party security programs do. I would think it would be really annoying if some security program popped up a dialog every time some process tried to do something it did not have the privileges for. Sounds like Vista is going to have just that sort of annoyance though some of that is probably anti-MS FUD.
On the download side, is there a way to force the download to go through the windows APIs that perform the proxy authentication? I think the Cygwin installer does something like that. I always used http://ntlmaps.sourceforge.net/ which is written in python and licensed under GPL.
...which effectively makes it incompatible with setuptools' licensing.
Maybe that can be used, unless I misunderstand the download issue.
The issue is that you still have to tell MAPS where to find the proxy settings, as well as the authentication info to use, even if you run it.
However, if someone wants to create a way to run a MAPS plugin for setuptools, I'll add entry point support so that it can be plugged in independently. That way, somebody can make a plugin egg that uses MAPS to provide proxy support, and *that* library would have to be GPL, but setuptools would not because it's just providing a generic customization hook for installed programs to be told when setuptools is about to do network access.
One could possibly even write some crazy plugin that actually used IE via COM to do the same thing, come to think of it, or to provide a GUI interface for downloading. :)
You might also want to think about a "just download, don't install" option, with the follow on of pretend I am running x version of Python on y platform, so that it would be possible to just go an get all the dependencies of a particular egg.
-Chris
On 10/4/06, Phillip J. Eby pje@telecommunity.com wrote:
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.
[...]
- 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.
As I said in a previous email, keep away from App Paths, and in particular, don't register an executable under any name but its own.
There's very little documentation that I could find on what App Paths should do, so all you've got to go on is experiment and looking at what others do. No-one that I have seen ever registers an exe under a different name. And some programs (4NT, for example) expect the App Path name to match the exe name (and give a broken user experience if that isn't true). Essentially, you're well into "undocumented behaviour" territory there, and things *will* go wrong.
Frankly, anyone using Start/Run *knows* that command line programs don't leave their window open. They know to start cmd, and type the command into that (even if they don't do anything else in cmd). Their expectations are right, don't break them by trying to be too clever.
Paul.
participants (3)
-
Chris Lambacher -
Paul Moore -
Phillip J. Eby