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

[Steve Dower]

On 03Feb2016 0150, Glenn Linderman wrote:
> 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.

Python has been registry independent for a while if you set the 
PYTHONHOME environment variable (and independent but potentially 
unreliable even without this).

Most of the registry settings created on install are for supporting 
upgrades, repairs and uninstallation, none of which matter in your case. 
(Also many python-dev readers' cases, but there are a lot of users who 
get into trouble very quickly without this level of management.)

> 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.

Agreed, and it already basically does this as mentioned above.

> 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.

You probably want the py.exe launcher here (though that relies on Python 
being registered...), as it handles shebangs - even /usr/bin/env style.

A script such as what you're asking for would be possible, but not 
something I want to be responsible for providing and maintaining.

> 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.

4-6 are basically the definition of an installer, and other installers 
are also able to do this.

> 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.

Perhaps you really want a script to run the installer and then pip?

Final point I want to reiterate - Python itself is essentially registry 
free already in that it does not need registry settings to function. The 
current problems are:

1. other programs need to locate all available Pythons
2. there appears to only be one space to register your Python
3. this space is *sometimes* used by Python to locate itself and 
installed packages

I want to fix problem 2 via documentation, and then look at the much 
more difficult problem 3.

Cheers,
Steve