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

[Paul Moore]

On 3 February 2016 at 16:46, Steve Dower <steve.dower at python.org> wrote:
> So a few high-level observations:
>
> * any program can install anywhere on the machine and make its libraries available to a specific version of Python by creating a subkey under 'PythonCore\x.y\PythonPath'

Yeah, that's horrid but not really something we can change without
compatibility breakage. But it's essentially opt-in - if you don't
need the feature you don't have to register anything under that key.

> * any environment lacking 'Lib\os.py' (e.g. venv) relies on the registry to locate enough stdlib to import site
> * this is too complicated, but guaranteed we will break users in production if we change it now
>
> So if repackagers follow a few rules (that I documented in https://docs.python.org/3.5/using/windows.html - I see the process above is also documented there, which I wish I remembered before writing all that out), they'll be fine. Unfortunately, following those rules means that you don't register anywhere that separate tools can find you, and so users complain and you "fix" it by doing the wrong thing.

Thanks for the explanation. And for documenting it (even if I looked
for the documentation, failed to find it and then whined about it not
being documented - my apologies!)

More specifically for the people wanting "portable" Python systems, if
I read that right then if python.exe is alongside a Lib directory
containing os.py, Python needs no environment variables, and no
registry entries, to run perfectly. I don't see any issue with Python
builds that don't register themselves not showing up in tools that
look for Python installations. And as you say, if we give people who
make "official" distributions a way to properly register, then that
helps them and leaves the unregistered case for "homebrew" portable
copies of Python.

(I've just seen your other note about it being "potentially
problematic". OK, let's leave it low-key for now, but when we are
comfortable with it, can we publicise it then? I get a definite
impression that quite a lot of people assume that "you can't have a
portable build of Python").

> This PEP offers a right way to fix it.

Thanks for the explanation, and I now agree that's what the PEP is doing.

So +0.5 from me for this PEP (Only 0.5, because I still have some
concerns that talking about registry entries in such detail gives the
impression that Python is tied to them more than it actually is. If
you can see a way of toning down the wording, then great, but better
to document the proposal accurately than to water it down because
people might get a mistaken impression).

>> It's possible that the reason the above two points have been missed is
>> because the proposal focuses purely on "informational" registry data.
>> But Python also modifies sys.path based on the registry entries - and
>> possibly has other behavioural changes as well. The pywin32 package,
>> in particular, makes use of this (it's a feature of pywin32 that I
>> disagree with and I wish it didn't do that, but it does, and it's a
>> very widely used package on Windows). So ignoring this aspect of
>> Python's behaviour is a big problem. (Also, what changes will pywin32
>> need to make to correctly support being installed into non-python.org
>> distributions when this proposal is implemented?)
>
> I haven't looked into pywin32's use of this recently - I tend to only use Christoph Gohlke's  wheels that don't register anything. But it is certainly a valid concern. Hopefully Mark Hammond is watching :)

Yeah, I've not checked if pywin32 still does this, it's a long time
since I really used it. Like you, I go for wheels only these days.

Paul