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

[Yuya Nishihara]

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.