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

Jun Wu quark at fb.com
Tue Oct 4 19:17:06 UTC 2016


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.

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". The idea is inspired by CSS: you can
have "border: 1px red", and then "border-width: 2px", "border-color: blue"
will override the "border" property.

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?



More information about the Mercurial-devel mailing list