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

[Matt Harbison]

On Fri, 13 Apr 2018 15:10:45 -0400, Gregory Szorc  
<gregory.szorc at gmail.com> wrote:

> On Fri, Apr 13, 2018 at 6:35 AM, Matt Harbison <mharbison72 at gmail.com>
> wrote:
>
>>
>> > On Apr 13, 2018, at 9:11 AM, Yuya Nishihara <yuya at tcha.org> wrote:
>> >
>> >> On Thu, 12 Apr 2018 13:35:50 -0400, Matt Harbison wrote:
>> >> # HG changeset patch
>> >> # User Matt Harbison <matt_harbison at yahoo.com>
>> >> # Date 1523332699 14400
>> >> #      Mon Apr 09 23:58:19 2018 -0400
>> >> # Node ID 986b51f15e9bce19b2f67573ff76612540320d1b
>> >> # Parent  2e0e61312a257708a70201427b31deba964e9b05
>> >> dispatch: add a whitelist map of commands to implicitly loaded
>> extensions
>> >

>> One thing I like about this is the user doesn’t have to do anything to
>> switch.  I can send out an email saying “upgrade to 4.6”, convert on the
>> server, and nothing changes for the developer. Otherwise, everyone has  
>> to
>> enable the extension in their user settings, or alias clone and pull to
>> enable it anyway.
>>
>
> I want to add a "capabilities" mechanism to hg.peer() and hg.repository()
> that makes the caller declare what features the returned repository must
> have. This would allow callers to say things like "I only want a  
> read-only
> repo," "I need to be able to speak wire protocol command X," etc. These
> capabilities would get passed down to the localrepo or peer layers for
> evaluation, where they may result in the constructed instance being a
> different type, having a different composition of methods, etc. This may
> seem orthogonal to command dispatch. However, I would eventually like
> @command's to self-declare what features they need. e.g. `log` would say  
> it
> needs a read-only repository. `update` would say it needs a repository  
> with
> a working directory. `commit` would say it needs a mutable repository. A
> command to update the narrow profile would require a repository type that
> can be narrowed. And the list goes on.
>
> For your immediate use case, getting the extension tie-ins could be
> difficult. Obviously the extension needs to be loaded in order for the
> extension to declare a "capability" for a requested repo/peer instance.
>
> 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.

> Alternatively, you could move the client pieces of LFS into core
> so no extension loading is needed.

That doesn't seem viable.  The revlog flagprocessors drag along all of the  
store code.  A commit hook and pretxnchangegroup hook scan the relevant  
csets to see if the requirement needs to be written out, and I can't  
justify inflicting that on all repos, unless there's an O(1) test in the  
changegroup/bundle that I'm not aware of.  And the prefetchfiles hook is  
needed to support `hg clone` and `hg pull -u`.

> That may still require a semaphore
> somewhere. I think that's the best long-term behavior. But I think we
> should shore up the storage interfaces and figure out the narrow/partial
> clone integration story before we do that. Maybe much of this work has
> already been done?

My backup plan of alias shadowing clone/pull to add '--config  
extensions.lfs=' was a bust too, but I can wait on this.  I'm having  
trouble digesting the sheer volume of changes, so I guess when you think  
this has been reworked enough, let me know.