[PATCH 3 of 3 RFC] chgserve: preimport enabled extensions

Yuya Nishihara yuya at tcha.org
Fri Oct 7 01:55:24 EDT 2016


On Tue, 4 Oct 2016 20:17:06 +0100, Jun Wu wrote:
> Excerpts from Yuya Nishihara's message of 2016-10-04 23:11:39 +0900:
> > Yeah, my initial idea was something like that, and I found :enabled would
> > work well for both chg and non-chg use cases. For instance, I can manage all
> > paths of third-party extensions in my ~/.hgrc, and enable them selectively
> > by repo/.hg/hgrc. Which seems an improvement over the current "!" syntax.
> 
> I agree it's better than the current syntax. Users would be able to use
> "extname:enabled = True" without setting "extname" to enable a builtin
> extension. As "configbool" defaults to False, we may want to use ":disabled"
> instead.

We have some default=True, which should be okay.

> When I was new to hg, the syntax of setting "extname=" to enable an
> extension looked pretty strange. I guess it does confuse users.
> 
> To make things even cleaner, it may be worthwhile to explicitly append
> ":path" to override the path setting, for example, you can have both or
> either or none of the two configs:
> 
>   extname:path    = path/to/ext.py
>   extname:enabled = True
> 
> "!" cannot be used in "extname:path".

Seems fine, but I have no preference about that because [paths] have a
similar syntax, paths.<name> and paths.<name>:<subopt>.

> That said, the issue I want to solve is different: I think it can be tricky
> for some strange extensions to be 100% side-effect free when being imported.
> So we need a way to deal with that, like blacklisting those extensions.
>
> Config is an option. But ideally, it's the extension itself telling chg to
> not import it, like having some magic string in the code, because the author
> of the extension knows best about the behavior, not the user. Having it in
> code also means we need a customized module loader, which is not what I
> really want to do because it's much more complex than a simple "__import__"
> call.
> 
> Alternatively, we can do a check afterwards - import the extension as mod,
> and check mod.importsideeffectfree - if it's "False", just abort and let the
> user change their configs. This is not very pretty but should simply work.
> What do you think?

Do we have no option to make these extensions import-free? Do they have
something should be done before uisetup() ?

If I had to implement one of them, I would choose the magic string for
simplicity. But I don't like it because it is different from what we currently
have, testedwith, buglink, etc.


More information about the Mercurial-devel mailing list