[PATCH 3 of 3 RFC] chgserve: preimport enabled extensions
Yuya Nishihara
yuya at tcha.org
Fri Oct 7 05:55:24 UTC 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