Matt Harbison <matt_harbison@yahoo.com> [Sun, 03 Oct 2021 20:11:42 -0400] rev 48193
packaging: update the certifi dependency
Not sure if this helps with recent certificate issues[1], but we might as well
keep this modern.
Note that certifi no longer claims py2 support, and there's a PR to add it back
in[2]. Py2 support was dropped in 2020.04.05.2 (which predates what's being
updated here). None of the *.py files have changed since the 2020.6.20 release,
and I was able to call `certifi.where()` in both a virtualenv and with
`hg debugshell` from an MSI install with this version, so we shouldn't be any
worse off than before.
[1] https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5745
[2] https://github.com/certifi/python-certifi/pull/154
Differential Revision: https://phab.mercurial-scm.org/D11609
Matt Harbison <matt_harbison@yahoo.com> [Sun, 19 Sep 2021 01:36:37 -0400] rev 48192
setup: stop packaging python3.dll and python3X.dll in the wheel distribution
Now that exewrapper is smart enough to find the DLLs it needs without help from
the build script, backout ed286d150aa8 and 2960b7fac966. Note that this will
require deleting the build/lib.win-amd64-3.X directory to actually remove it
from the final wheel.
Differential Revision: https://phab.mercurial-scm.org/D11455
Matt Harbison <matt_harbison@yahoo.com> [Sun, 19 Sep 2021 01:23:16 -0400] rev 48191
exewrapper: find the proper python3X.dll in the registry
Previously, we relied on the default library lookup[1], which for us is
essentially to look on `PATH`. That has issues- the Python installations are
not necessarily on `PATH`, so I started copying the DLLs locally in 2960b7fac966
and ed286d150aa8 during the build to work around that. However, it's been
discovered that causes `python3.dll` and `python3X.dll` to get slipped into the
wheel that gets distributed on PyPI. Additionally, Mercurial would fail to run
in a venv if the Python environment that created it isn't on `PATH`, because
venv creation doesn't copy the DLLs locally.
The logic here is inspired by the `py.exe` launcher[2], though this is simpler
because we don't care about the architecture- if this is a 32 bit process
running on Win64, the registry reflection will redirect to where the 32 bit
Python process wrote its keys. A nice unintended side effect is to also make
venvs that don't have their root Python on `PATH` work without all of the code
required to read `pyvenv.cfg`[3]. I don't see any reasonable way to create a
venv without Python being installed (other than maybe building Python from
source?), so punt on trying to read that file for now and save a bunch of string
manipulation code.
I somehow managed to corrupt my Windows user profile, and that makes the
Microsoft Store python not run (even loading the DLL gives an access error), so
I'm giving priority to both global and user specific python.org installations.
Loading python3.dll is new, but when I went down the rabbit hole of implementing
`pyvenv.cfg` support, I saw a comment[4] that led me to think we could have
trouble if we don't. The comment in ed286d150aa8 confirms this, so we should
probably bail out completely if Python3 can't be loaded from the registry,
rather than getting something random on `PATH`. But I'll leave that for the
default branch.
[1] https://docs.microsoft.com/en-us/windows/win32/Dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications
[2] https://github.com/python/cpython/blob/adcd2205565f91c6719f4141ab4e1da6d7086126/PC/launcher.c#L249
[3] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/PC/getpathp.c#L707
[4] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/PC/getpathp.c#L1098
Differential Revision: https://phab.mercurial-scm.org/D11454