[bug#48232] [PATCH 0/2] Add mercurial-commitsigs and some changes to Mercurial.

[Ludovic Courtès]

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’.