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

Alexander Walters tritium-list at sdamon.com
Wed Feb 3 03:15:56 EST 2016

...just when I thought I have solved the registry headaches I have been dealing with...

I am not saying this proposal will make the registry situation worse, but it may break my solution to the headaches Python's registry use causes with some non-standard module installers (and even the standard distutils exe installers, but that is being mitigated). In the wild exist modules with their own EXE or MSI installers that check the registry for 'the system python'. No matter how hard you hit them, they will only install to that one python. You can imagine the sadist that builds such an installer would not be receptive to the concept of wheels. So in order to force those modules to install to the python YOU want, dammit, you have to edit the registry. I have (contributed to) a script that just sets whatever python it was last run with to the one true system python. Works with virtualenvs too.This is not a terribly obscure script either, by the way. It is in the first reply to the google search for "how to install exes in a virtualenv".

So here I am in a situation where some pythons use another registry entry. I have no idea if this makes my life as a user harder. What does this kind of meddling do against tools trying to autodetect python, and finding an ever changing value? Are we trying to guarantee that the keys used by the python.org installers or only ever actually used by standard CPython?

I know for PTVS manually adding a python environment to visual studio is trivial - you fill in three locations, and its done. Just today I added a python environment to my system that was not autodetected. It took under a minute and almost no effort to add it... so for that tool this adds very little benefit. I do not know about other tools.

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.

On 2/3/2016 00:15, Steve Dower wrote:

I was throwing around some ideas with colleagues about how we detect Python installations on Windows from within Visual Studio, and it came up that there are many Python distros that install into different locations but write the same registry entries. (I knew about this, of course, but this time I decided to do something.)

Apart from not being detected properly by all IDEs/tools/installers, non-standard distros that register themselves in the official keys may also mess with the default sys.path values. For example, at one point (possibly still true) if you installed both Canopy and Anaconda, you would break the first one because they tried to load the other's stdlib. Other implementations have different structures or do not register themselves at all, which also makes it more complicated for tools to discover them. So here is a rough proposal to standardise the registry keys that can be set on Windows in a way that (a) lets other installers besides the official ones have equal footing, (b) provides consistent search and resolution semantics for tools, and (c) includes slightly more rich metadata (such as display names and URLs). Presented in PEP-like form here, but if feedback suggests just putting it in the docs I'm okay with that too. It is fully backwards compatible with official releases of Python (at least back to 2.5, possibly further) and does not require modifications to Python or the official installer - it is purely codifying a superset of what we already do. Any and all feedback welcomed, especially from the owners of other distros, Python implementations or tools on the list. Cheers, Steve ----- PEP: ??? Title: Python environment registration in the Windows Registry Version: RevisionRevisionRevision Last-Modified: DateDateDate Author: Steve Dower <steve.dower at python.org> Status: Draft Type: ??? Content-Type: text/x-rst Created: 02-Feb-2016

Abstract ======== When installed on Windows, the official Python installer creates a registry key for discovery and detection by other applications. Unofficial installers, such as those used by distributions, typically create identical keys for the same purpose. However, these may conflict with the official installer or other distributions. This PEP defines a schema for the Python registry key to allow unofficial installers to separately register their installation, and to allow applications to detect and correctly display all Python environments on a user's machine. No implementation changes to Python are proposed with this PEP. The schema matches the registry values that have been used by the official installer since at least Python 2.5, and the resolution behaviour matches the behaviour of the official Python releases. Specification ============= We consider there to be a single collection of Python environments on a machine, where the collection may be different for each user of the machine. There are three potential registry locations where the collection may be stored based on the installation options of each environment. These are:: HKEYCURRENTUSER\Software\Python<Company><Tag> HKEYLOCALMACHINE\Software\Python<Company><Tag> HKEYLOCALMACHINE\Software\Wow6432Node\Python<Company><Tag> On a given machine, an environment is uniquely identified by its Company-Tag pair. Keys should be searched in the order shown, and if the same Company-Tag pair appears in more than one of the above locations, only the first occurrence is offerred. Official Python releases use PythonCore for Company, and the value of sys.winver for Tag. Other registered environments may use any values for Company and Tag. Recommendations are made in the following sections.

Backwards Compatibility ----------------------- Python 3.4 and earlier did not distinguish between 32-bit and 64-bit builds in sys.winver. As a result, it is possible to have valid side-by-side installations of both 32-bit and 64-bit interpreters. To ensure backwards compatibility, applications should treat environments listed under the following two registry keys as distinct, even if Tag matches:: HKEYLOCALMACHINE\Software\Python\PythonCore<Tag> HKEYLOCALMACHINE\Software\Wow6432Node\Python\PythonCore<Tag> Note that this does not apply to Python 3.5 and later, which uses different Tags. Environments registered under other Company names must use distinct Tags for side-by-side installations. 1. Environments in HKEYCURRENTUSER are always preferred 2. Environments in HKEYLOCALMACHINE\Software\Wow6432Node are preferred if the interpreter is known to be 32-bit Company ------- The Company part of the key is intended to group related environments and to ensure that Tags are namespaced appropriately. The key name should be alphanumeric without spaces and likely to be unique. For example, a trademarked name, a UUID, or a hostname would be appropriate:: HKEYCURRENTUSER\Software\Python\ExampleCorp HKEYCURRENTUSER\Software\Python\6C465E66-5A8C-4942-9E6A-D29159480C60 HKEYCURRENTUSER\Software\Python\www.example.com If a string value named DisplayName exists, it should be used to identify the environment category to users. Otherwise, the name of the key should be used. If a string value named SupportUrl exists, it may be displayed or otherwise used to direct users to a web site related to the environment. A complete example may look like:: HKEYCURRENTUSER\Software\Python\ExampleCorp (Default) = (value not set) DisplayName = "Example Corp" SupportUrl = "http://www.example.com" Tag --- The Tag part of the key is intended to uniquely identify an environment within those provided by a single company. The key name should be alphanumeric without spaces and stable across installations. For example, the Python language version, a UUID or a partial/complete hash would be appropriate; an integer counter that increases for each new environment may not:: HKEYCURRENTUSER\Software\Python\ExampleCorp\3.6 HKEYCURRENTUSER\Software\Python\ExampleCorp\6C465E66 If a string value named DisplayName exists, it should be used to identify the environment to users. Otherwise, the name of the key should be used. If a string value named SupportUrl exists, it may be displayed or otherwise used to direct users to a web site related to the environment. If a string value named Version exists, it should be used to identify the version of the environment. This is independent from the version of Python implemented by the environment. If a string value named SysVersion exists, it must be in x.y or x.y.z format matching the version returned by sys.versioninfo in the interpreter. Otherwise, if the Tag matches this format it is used. If not, the Python version is unknown. Note that each of these values is recommended, but optional. A complete example may look like this:: HKEYCURRENTUSER\Software\Python\ExampleCorp\6C465E66 (Default) = (value not set) DisplayName = "Distro 3" SupportUrl = "http://www.example.com/distro-3" Version = "3.0.12345.0" SysVersion = "3.6.0" InstallPath ----------- Beneath the environment key, an InstallPath key must be created. This key is always named InstallPath, and the default value must match sys.prefix:: HKEYCURRENTUSER\Software\Python\ExampleCorp\3.6\InstallPath (Default) = "C:\ExampleCorpPy36" If a string value named ExecutablePath exists, it must be a path to the python.exe (or equivalent) executable. Otherwise, the interpreter executable is assumed to be called python.exe and exist in the directory referenced by the default value. If a string value named WindowedExecutablePath exists, it must be a path to the pythonw.exe (or equivalent) executable. Otherwise, the windowed interpreter executable is assumed to be called pythonw.exe and exist in the directory referenced by the default value. A complete example may look like:: HKEYCURRENTUSER\Software\Python\ExampleCorp\6C465E66\InstallPath (Default) = "C:\ExampleDistro30" ExecutablePath = "C:\ExampleDistro30\expython.exe" WindowedExecutablePath = "C:\ExampleDistro30\expythonw.exe" Help ---- Beneath the environment key, a Help key may be created. This key is always named Help if present and has no default value. Each subkey of Help specifies a documentation file, tool, or URL associated with the environment. The subkey may have any name, and the default value is a string appropriate for passing to os.startfile or equivalent. If a string value named DisplayName exists, it should be used to identify the help file to users. Otherwise, the key name should be used. A complete example may look like:: HKEYCURRENTUSER\Software\Python\ExampleCorp\6C465E66\Help _Python_ (Default) = "C:\ExampleDistro30\python36.chm" DisplayName = "Python Documentation" _Extras_ (Default) = "http://www.example.com/tutorial" DisplayName = "Example Distro Online Tutorial"

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com

More information about the Python-Dev mailing list