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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
