On 3 February 2016 at 16:46, Steve Dower email@example.com 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.