[Python-Dev] Python environment registration in the Windows Registry

[Glenn Linderman]

On 2/3/2016 12:15 AM, Alexander Walters wrote:
> On a very personal note (like the rest of this wasn't my personal 
> issues with possibly making my life slightly more difficult), I would 
> much rather see python stop touching the registry all together - but I 
> have no strong argument for that. 

Me too. My opinions follow, some might call them arguments, strong or 
weak, some might call them foolishness.

I've been setting up a collection of tools and programs on Dropbox for 
far-flung project team members (users, not programmers) to share. It is 
nearly impossible to install a typical Windows program on Dropbox, 
because the installation information is partly in the installed 
directory structure, and partly in the registry. Exporting registry info 
from the machine that does the install to other machines is hard because 
other users have different paths to Dropbox. OK, for commercial 
software, installing to Dropbox probably violates some of the licensing, 
forcing each user to buy/install, but FOSS or in-house software doesn't 
have such restrictions: but still, most of it wants to use the registry, 
and Windows almost, but doesn't quite, force it to.

Portable software exists, but often is 3rd party hacks of popular FOSS 
rather than being directly supported by the FOSS development team.  
Python falls into this category. Happily, I recently found WinPython 
Zero, which hacks it (somehow) to work portably, and I've deployed it 
successfully on Dropbox. I'd rather Python were portable on its own, 
without hacks.

Portability requires not using the registry, so I agree with Alexander 
there.

Portability, as "Windows portable software" is generally defined, is 
focused on moving programs and data around on a flash drive, from one 
computer to another, and is focused on single-user, any (Windows) 
machine (with sufficient specs).

That doesn't quite fit the Dropbox environment. Most portable software 
reintroduces the idea of storing configuration information in the 
program folder, which is OK for "project" configuration info, done once, 
by one person, but not for "personal preferences".

The other thing Windows GUI lost is the concept of "current working 
directory", which hit me hard when I first started trying to set up 
project working areas on Dropbox. Many Windows programs want to run only 
one copy of themselves, in one Window, with one set of settings, and one 
"Start In" directory (which generally defaults to .... the program 
directory, or sometimes to "My Documents".  This is why I went looking 
for a portable Python (and other portable things), and I finally 
realized that I was "fighting city hall" in trying to get an environment 
set up that was usable for the various teams (of users, not developers). 
Writeup at slashdot 
<http://slashdot.org/firehose.pl?op=view&id=80569101> for more details 
on the lack of a "current working directory" concept in Windows GUI 
programs.

The path to Dropbox folders is different for everyone, even the drive 
letter can be different.

So here are my preferences for CPython:

1) It would be best CPython itself were fully portable. That wherever 
you point the installer, it lives there, and if somehow you happen to 
execute it from that directory, it would use its invocation path as the 
basis for finding the rest of the installed pieces.

2) A script could be provided that sets the association for .py and the 
corresponding ftype to point to the python that executed the script... 
and which has a parameter to clear that back out, too. This would be to 
allow users to set a particular python for convenient script execution, 
since Windows does the association thing, instead of using #! lines.

3) A script could be provided (maybe the one Alexander referred to) that 
sets the registry so that the "apparently one true System Python" points 
to the python that executed the script... and which has a parameter to 
clear that back out, too.  This would be for compatible transition to 
the new registry-free Python versions for packages that have weird 
installers (such as Alexander alluded to). But with the registry-free 
Python available, those packages would hopefully see the future is 
registry free, and avoid requiring registry data to do installs.

4) A script could be provided to add the python that executed the script 
to the PATH, with an option to remove it.

5) A script could be provided to add the python that executed the script 
to the launcher .ini file, with an option to remove it.

6) A script could be provided to add the python that executed it to the 
Start menu, and/or Desktop icons, with an option to remove them.

Maybe scripts 2-6 are all the same one, with different options (or 
different invocation shortcuts for the clicky folk). Not everyone would 
probably need all the scripts, but none of them would be particularly 
large, such that they would be burdensome for others to ignore.

Such a collection of scripts would allow folks to achieve various levels 
of integration with Windows "conveniences", without requiring it. The 
portability would allow Python to be installed on Dropbox or a network 
share, and used from there without requiring every team member to do all 
the individual installs of the packages needed for a project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160203/c1cb4f3a/attachment.html>