| Message ID | 87k0oecj3a.fsf@yoctocell.xyz |
|---|---|
| Headers | show |
| Series | Add mercurial-commitsigs and some changes to Mercurial. | expand |
Hi, Xinglu Chen <public@yoctocell.xyz> skribis: > The first patch adds the commitsigs extension for Mercurial, it allows > users to sign Mercurial changesets (equivalent to Git commits) with > GnuPG or OpenSSL. > > The second patch adds PYTHONPATH to the ‘native-search-paths’ field of > Mercurial, this allows Mercurial to automatically find third-party > extensions (like commitsigs) installed in > /gnu/store/...-profile/lib/python3.8/site-packages/hgext3rd. By > default, it only looks at > /gnu/store/...-mercurial/lib/python3.8/site-packages/hgext3rd. Is /hgext3rd a convention that upstream recommends? > However, I am not sure this is the best approach since it messes with > PYTHONPATH, AFAIK there is no such things as a HGEXTENSIONS variable I > could set. Another problem is that I have to hardcode “python3.8”, this > would obviously have to be updated if the default Python version gets > updated. I did try to do something like this: Messing up with PYTHONPATH is indeed not great since it “belongs” to Python. Could we instead patch Mercurial so it honors a specific environment variable, like HG_EXTENSION_PATH? Thanks, Ludo’.
On Tue, May 11 2021, Ludovic Courtès wrote: > Hi, > > Xinglu Chen <public@yoctocell.xyz> skribis: > >> The second patch adds PYTHONPATH to the ‘native-search-paths’ field of >> Mercurial, this allows Mercurial to automatically find third-party >> extensions (like commitsigs) installed in >> /gnu/store/...-profile/lib/python3.8/site-packages/hgext3rd. By >> default, it only looks at >> /gnu/store/...-mercurial/lib/python3.8/site-packages/hgext3rd. > > Is /hgext3rd a convention that upstream recommends? I don’t think they mention it in their docs, but the hgext3rd/ directory already contained one file (__init__.py), and I have seen one Mercurial extension that put their Python files in a hgext3rd/ directory[1]. >> However, I am not sure this is the best approach since it messes with >> PYTHONPATH, AFAIK there is no such things as a HGEXTENSIONS variable I >> could set. Another problem is that I have to hardcode “python3.8”, this >> would obviously have to be updated if the default Python version gets >> updated. I did try to do something like this: > > Messing up with PYTHONPATH is indeed not great since it “belongs” to > Python. > > Could we instead patch Mercurial so it honors a specific environment > variable, like HG_EXTENSION_PATH? I am not familiar with the Mercurial codebase, but I guess we could try. Or perhaps we could wrap the ‘hg’ binary to set PYTHONPATH so it finds the extensions. [1]: https://foss.heptapod.net/mercurial/hg-credentials
Xinglu Chen <public@yoctocell.xyz> skribis: > On Tue, May 11 2021, Ludovic Courtès wrote: > >> Hi, >> >> Xinglu Chen <public@yoctocell.xyz> skribis: >> >>> The second patch adds PYTHONPATH to the ‘native-search-paths’ field of >>> Mercurial, this allows Mercurial to automatically find third-party >>> extensions (like commitsigs) installed in >>> /gnu/store/...-profile/lib/python3.8/site-packages/hgext3rd. By >>> default, it only looks at >>> /gnu/store/...-mercurial/lib/python3.8/site-packages/hgext3rd. >> >> Is /hgext3rd a convention that upstream recommends? > > I don’t think they mention it in their docs, but the hgext3rd/ directory > already contained one file (__init__.py), and I have seen one Mercurial > extension that put their Python files in a hgext3rd/ directory[1]. OK, sounds good. >>> However, I am not sure this is the best approach since it messes with >>> PYTHONPATH, AFAIK there is no such things as a HGEXTENSIONS variable I >>> could set. Another problem is that I have to hardcode “python3.8”, this >>> would obviously have to be updated if the default Python version gets >>> updated. I did try to do something like this: >> >> Messing up with PYTHONPATH is indeed not great since it “belongs” to >> Python. >> >> Could we instead patch Mercurial so it honors a specific environment >> variable, like HG_EXTENSION_PATH? > > I am not familiar with the Mercurial codebase, but I guess we could try. > Or perhaps we could wrap the ‘hg’ binary to set PYTHONPATH so it finds > the extensions. I think wrapping is not an option because the wrapper doesn’t know where the profile is. Let’s see if you can adjust hg to honor a new environment variable, and if not, we’ll see… Thanks! Ludo’.
On Tue, May 11 2021, Ludovic Courtès wrote: >>>> However, I am not sure this is the best approach since it messes with >>>> PYTHONPATH, AFAIK there is no such things as a HGEXTENSIONS variable I >>>> could set. Another problem is that I have to hardcode “python3.8”, this >>>> would obviously have to be updated if the default Python version gets >>>> updated. I did try to do something like this: >>> >>> Messing up with PYTHONPATH is indeed not great since it “belongs” to >>> Python. >>> >>> Could we instead patch Mercurial so it honors a specific environment >>> variable, like HG_EXTENSION_PATH? >> >> I am not familiar with the Mercurial codebase, but I guess we could try. >> Or perhaps we could wrap the ‘hg’ binary to set PYTHONPATH so it finds >> the extensions. > > I think wrapping is not an option because the wrapper doesn’t know where > the profile is. Oh, right. > Let’s see if you can adjust hg to honor a new environment variable, > and if not, we’ll see… Hmm, I will try to see what I can do.
Changes since v1: * Patch Mercurial to make it read the HGEXTENSIONPATH environment variable to make it load third-party extensions. * Rename ‘mercurial-commitsigs’ to ‘hg-commitsigs’ because to keep things more consistent (we already have ‘python-hg-evolve’, not sure if the ‘python-’ prefix is necessary, though). Xinglu Chen (2): gnu: Add hg-commitsigs. gnu: mercurial: Patch to make it read HGEXTENSIONPATH. gnu/local.mk | 1 + .../patches/mercurial-hg-extension-path.patch | 29 ++++++++ gnu/packages/version-control.scm | 69 +++++++++++++++++++ 3 files changed, 99 insertions(+) create mode 100644 gnu/packages/patches/mercurial-hg-extension-path.patch base-commit: fbb099a4481ce682bdaaaffea619c5273fd0d3b0
The first patch adds the commitsigs extension for Mercurial, it allows users to sign Mercurial changesets (equivalent to Git commits) with GnuPG or OpenSSL. The second patch adds PYTHONPATH to the ‘native-search-paths’ field of Mercurial, this allows Mercurial to automatically find third-party extensions (like commitsigs) installed in /gnu/store/...-profile/lib/python3.8/site-packages/hgext3rd. By default, it only looks at /gnu/store/...-mercurial/lib/python3.8/site-packages/hgext3rd. However, I am not sure this is the best approach since it messes with PYTHONPATH, AFAIK there is no such things as a HGEXTENSIONS variable I could set. Another problem is that I have to hardcode “python3.8”, this would obviously have to be updated if the default Python version gets updated. I did try to do something like this: #+begin_src scheme (string-append "lib/python" (string-join (drop-right (string-split (package-version python) #\.) 1) ".") "/site-packages/hgext3rd") #+end_src but it just gave me a confusing error message when trying to build it; it worked fine if I hit {C-x C-e} in Emacs, though. What we could do instead is to delegate the work of installing Mercurial extensions to Guix Home[1] (I am currently working on adding a service for Mercurial[2]) and add a ‘mercurial-extension-file-path’ key to the ‘properties’ field of Mercurial extensions so Guix Home can tell Mercurial where to find the extension by the relevant lines in hgrc. We could have a package definition like this: #+begin_src scheme (package (name "mercurial-commitsigs") ... (properties '((mercurial-extension-file-path . "commitsigs.py")))) #+end_src hgrc: #+begin_src [extensions] commitsigs = /gnu/store/...-mercurial-commitsigs/commitsigs.py #+end_src [1]: https://yhetil.org/guix-devel/878s6u2pco.fsf@trop.in/ [2]: https://lists.sr.ht/~abcdw/rde-devel/patches/22421 Xinglu Chen (2): gnu: Add mercurial-commitsigs. gnu: mercurial: Add PYTHONPATH to ‘native-search-paths’. gnu/packages/version-control.scm | 68 ++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) base-commit: aa7eeabe9a782afc2535581298990050d16b1895