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

Steve Dower steve.dower at python.org
Wed Feb 3 11:17:59 EST 2016


On 03Feb2016 0015, Alexander Walters wrote:
> 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.

(I agree, but maybe if you can point them to a PEP it'll help? Right 
now, there's nowhere to even point them to.)

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

I highly doubt it will break your current solution, as everyone pre- and 
post-update will still look in PythonCore\X.Y for Python.

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

Guaranteeing that only python.org Python uses PythonCore is part of it, 
but the other part is officially telling everyone else that they are 
welcome to create their own keys.

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

I'm also a PTVS maintainer, so I know how much magic is going on behind 
those three locations :) But I don't think people should need to do that 
by hand at all.

For example, the path to an Anaconda installation is buried deep inside 
AppData (as is Python 3.5+ now), and varies based on your username. 
Canopy does the same, and once you've found it there are (or were?) at 
least three copies of python.exe to choose from (we worked with 
Enthought to make this Just Work for PTVS users).

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

I also agree with that, but ultimately the registry is the global 
configuration store on Windows, and when we need global state it is the 
place to go. (My actual hope for Python 3.6 is to drop the few places 
where Python *reads* from the registry for configuration that shouldn't 
be global, at which point the Python key is solely for other programs. 
But those fixes are probably not PEP-worthy.)

Cheers,
Steve




More information about the Python-Dev mailing list