[PATCH 1 of 6] extensions: import the exthelper class from evolve ff799015d62e

[Boris FELD]

On 12/2/18 12:37 PM, Yuya Nishihara wrote:
> On Fri, 30 Nov 2018 23:10:55 -0500, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison <matt_harbison at yahoo.com>
>> # Date 1543121473 18000
>> # Sat Nov 24 23:51:13 2018 -0500
>> # Node ID d5a04a8016a270dce028bddb2483509e0429f113
>> # Parent 33d30fb1e4ae52a283ef487ccf5dfbe59b8a5a68
>> extensions: import the exthelper class from evolve ff799015d62e

>> It was copied unmodified, except:
>> - fix up the imports
>> - rename final_xxxsetup() -> finalxxxsetup() to appease checkcode
>> - avoid a [] default arg to wrapcommand()
>> - adjust the module name used to load the templates and revsets

It would be nice if we kept the same API for the evolve and core, this
would help evolve to smoothly transition to the core one eventually.

Should we keep the `final_` form in core or should we move to the more
compact one for evolve?

The module name for templates and revsets could be a mandatory argument
to the exthelper object (at least the top level one).

eh = exthelper('lfs')

(note: We pushed a couple of the API improvement to evolve.)


>> I'm not sure what licensing info to put in place, since it wasn't
>> available on
>> the original copy.
>
> Boris?

 Something similar to the extension header would do. We pushed a
changeset to clarify copyright and license of the exthelper.py module to
evolve. You can reuse that.

>> + def configitem(self, section, config,
>> default=configitems.dynamicdefault):
>> + """Register a config item.
>> + """
>> + self._configitem(section, config, default=default)
>
> What's the point of reinventing the registrar functions?

Strictly speaking, the registrar is reinventing exthelper ;-) exthelper
has been around for twice as long :-)

> I understand it will be useful to provide decorators for various setup
> hooks, but we have registrar API for table registrations. And less coupled
> abstraction is generally better.

The exthelper method to register items stayed around after registrar
introduction because of one specific feature: exthelper merging.

A key feature of registrar is to be able to combine submodule instance
with top level one. You create an instance in the sub module and
decorate everything that needs to be decorated. Then in the higher level
module, you can simply merge the submodule exthelper instance with the
local one, everything necessary declaration will be propagated.

The registrar API requires the xxxtable to be explicitly declared and
passed to the registrar function. This is a significant limitation.