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

[Gregory Szorc]

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
> >
> >> class request(object):
> >>     def __init__(self, args, ui=None, repo=None, fin=None, fout=None,
> >>                  ferr=None, prereposetups=None):
> >> @@ -843,6 +852,20 @@ def _dispatch(req):
> >>         fullargs = args
> >>         cmd, func, args, options, cmdoptions = _parse(lui, args)
> >>
> >> +        # resolve aliases back to the core function
> >> +        entrypoint = func
> >> +        if isinstance(entrypoint, cmdalias):
> >> +            entrypoint = entrypoint.fn
> >> +
> >> +        if entrypoint in extensionwhitelist:
> >> +            configured = [ext for (ext, _path) in
> ui.configitems("extensions")]
> >> +            missing = [ext for ext in extensionwhitelist[entrypoint]
> >> +                       if ext not in configured]
> >> +            for ext in missing:
> >> +                ui.setconfig('extensions', ext, '', source='internal')
> >> +            if missing:
> >> +                extensions.loadall(ui, missing)
> >
> > I'm -1 on this because loading extra Python module isn't always instant,
> and
> > the loaded extension persists forever, which can be a problem for
> command-server
> > process.
>
> Good point. Any alternate ideas?  I wasn’t sure what the bundlepart idea
> would look like, because presumably this needs to be loaded pretty early in
> the startup process.
>
> 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. Alternatively, you could move the client pieces of LFS into core
so no extension loading is needed. 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20180413/a2d355ed/attachment.html>