[PATCH] dispatch: add a whitelist map of commands to implicitly loaded extensions

Matt Harbison mharbison72 at gmail.com
Sat Apr 14 14:09:42 EDT 2018


On Sat, 14 Apr 2018 03:09:01 -0400, Yuya Nishihara <yuya at tcha.org> wrote:

> On Fri, 13 Apr 2018 23:30:43 -0400, Matt Harbison wrote:
>> On Fri, 13 Apr 2018 15:10:45 -0400, Gregory Szorc
>> <gregory.szorc at gmail.com> wrote:
>> > What we may want instead is to key things off .hg/requires or a
>> > to-be-invented supplemental requirements-like file that declares soft
>> > features. localrepository.__init__ could then load trusted extensions  
>> at
>> > repo open time if a requirements/capability was present/requested.  
>> i.e.
>> > if
>> > you talk to an LFS server, write a semaphore somewhere into .hg/ and  
>> have
>> > something in core look for that and automatically load lfs if present.
>> > This would get you the "automatically enable LFS when talking to LFS
>> > servers"
>> > benefits.
>>
>> Sounds promising.  One of the things the lfs extension is doing is  
>> writing
>> '[extensions]\nlfs=' to the repo's local hgrc file in a commit hook (it
>> should probably be handling transactions too).  So it would be nice if
>> this was baked into the core somehow (largefiles could use exactly the
>> same handling, and I'm assuming narrow will be similar).  It's also
>> manually adding to the requires file, since that doesn't seem to be
>> updated in exchange.
>>
>> Assuming the semaphore is persistent, it could be beneficial to load
>> extensions indicated by it around the normal load time (e.g., largefiles
>> wraps the clone command and adds extra switches).
>>
>> I'm not sure if this addresses Yuya's concern about long lived processes
>> though.
>
> If the extensions to be loaded are bound to a repo, yes, that should be
> fine. A well-designed extension should check the repo requirements. What
> doesn't work in command server is to load extensions per-command basis.

While "bound to a repo" makes it sound like the extension would be  
isolated and could unload if the repo is GC'd, what I don't get is what  
that phrase means for all of the module functions that are wrapped.


More information about the Mercurial-devel mailing list