[Python-Dev] Python environment registration in the Windows Registry (original) (raw)

Steve Dower steve.dower at python.org
Wed Feb 3 11:29:39 EST 2016

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

More information about the Python-Dev mailing list