<div>Update in case anybody else wants the info:</div>
<div> </div>
<div>** Caveat - I've only tried this on XP Professional</div>
<div> </div>
<div>If you copy the files from your python installation (i.e. C:\Python24), and try to run python.exe on a machine where python is not installed, you get errors for a few .dll files not found. Copy them into the same folder as
python.exe, and you're in business (I think this is specific to how XP handles .dll's)</div>
<div> </div>
<div>PyWin32 also has at least 1 .dll which must be copied in as well to work.</div>
<div> </div>
<div>Having done this, I was up and running with everything under \Lib, including site-packages. Copying the wxpython docs and demos, however, only mostly worked. Some of the 'deeper' modules wouldn't import (like the Flash window as an ActiveX control). At that point I did a lot of reading about how the import statement works 'under the hood', how windows associates file extensions to programs, environment variables, etc...
</div>
<div> </div>
<div>I don't think I can summarize all of that stuff very well. It's very interesting if you find such things interesting.</div>
<div> </div>
<div>I have gone into windows explorer, chose Tools->Folder Options -> (don't remember exactly from here and this definately depends on Windows version), set .py files to go to pythonw.exe, and that has everything working with a double click, even the funky wxpython demo stuff.
</div>
<div> </div>
<div>Long story short (and these are educated guesses until I do some more tinkering) - I believe:</div>
<div> </div>
<div>1. A windows user without admin authority cannot run an installer, or edit HKEY_LOCAL_MACHINE.</div>
<div> </div>
<div>2. A windows user without admin authority can edit HKEY_CURRENT_USER. (When you pick what program should open .mp3 files, that's writing here)</div>
<div> </div>
<div>3. Whenever Windows cares about anything that would be in HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER is checked first (I'm not very sure how universal this is, but it is definately true sometimes at least)</div>
<div> </div>
<div>4. Installers typically write to HKEY_LOCAL_MACHINE, the Python installers choice between install for all users or install just for me is really letting you choose between HKEY_LOCAL_MACHINE and HKEY_CURRENT _USER.</div>
<div> </div>
<div>5. Through regedit, you can export any piece of the registry, or the whole thing. The output is essentially text.</div>
<div> </div>
<div>6. By comparing snapshots of the registry before and after an install, you can find all keys an installer added / deleted / edited</div>
<div> </div>
<div>7. IF (and it's a big if) my set of assumptions are correct, I can write a utility to 'watch' an install, translating the local machine keys to current user keys. I can also write a utility to use that output to make any installed program 'portable'. It would check for the appropriate keys first, and add them if needed, mapping the paths based on it's own location. There's probably even a way to have these keys removed with the next system shutdown. At that point, anything could live on a CD or USB drive, waiting for you to pop it into any arbitrary windows machine and run it.
</div>
<div> </div>
<div>I'm pretty happy with results so far. I have Python on a shared network drive living on a file and print server, but I can run scripts from machines where I'm not an admin without installing after 10 - 20 seconds of setup. I will keep tinkering (and reporting results) though. At this point it's worth it as a learning exercise. I've learned as much about Windows and Python internals in the past few weeks as I had in the past few years.
</div>
<div> </div>
<div>Hope somebody finds this helpful, and input is appreciated as always!</div>