##// END OF EJS Templates
exewrapper: find the proper python3X.dll in the registry...
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
Matt Harbison -
r48993:67d14d4e default
Show More
Name Size Modified Last Commit Author
contrib
doc
hgdemandimport
hgext
hgext3rd
i18n
mercurial
relnotes
rust
tests
.arcconfig Loading ...
.clang-format Loading ...
.editorconfig Loading ...
.hgignore Loading ...
.hgsigs Loading ...
.hgtags Loading ...
.jshintrc Loading ...
CONTRIBUTING Loading ...
CONTRIBUTORS Loading ...
COPYING Loading ...
Makefile Loading ...
README.rst Loading ...
hg Loading ...
hgeditor Loading ...
hgweb.cgi Loading ...
pyproject.toml Loading ...
rustfmt.toml Loading ...
setup.py Loading ...

Mercurial

Mercurial is a fast, easy to use, distributed revision control tool for software developers.

Basic install:

$ make            # see install targets
$ make install    # do a system-wide install
$ hg debuginstall # sanity-check setup
$ hg              # see help

Running without installing:

$ make local      # build for inplace usage
$ ./hg --version  # should show the latest version

See https://mercurial-scm.org/ for detailed installation instructions, platform-specific notes, and Mercurial user information.

Notes for packagers

Mercurial ships a copy of the python-zstandard sources. This is used to provide support for zstd compression and decompression functionality. The module is not intended to be replaced by the plain python-zstandard nor is it intended to use a system zstd library. Patches can result in hard to diagnose errors and are explicitly discouraged as unsupported configuration.