##// 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

File last commit:

r45111:c5653cf2 default
r48993:67d14d4e default
Show More
TODO.md
30 lines | 1.1 KiB | text/x-minidsrc | MarkdownLexer

Octopus Merge Support

This will be moderately complicated, as we'll need to synthesize phony
changeset entries to explode the octopus into "revisions" that only
have two parents each. For today, we can probably just do something like

aaaaaaaaaaaaaaaaaaXX{20 bytes of exploded node's hex sha}

where XX is a counter (so we could have as many as 255 parents in a
git commit - more than I think we'd ever see.) That means that we can
install some check in this extension to disallow checking out or
otherwise interacting with the aaaaaaaaaaaaaaaaaa revisions.

Interface Creation

We at least need an interface definition for changelog in core that
this extension can satisfy, and again for basicstore.

Reason About Locking

We should spend some time thinking hard about locking, especially on
.git/index etc. We're probably adequately locking the git
repository, but may not have enough locking correctness in places
where hg does locking that git isn't aware of (notably the working
copy, which I believe Git does not lock.)