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

[Yuya Nishihara]

On Mon, 3 Oct 2016 18:57:58 +0100, Jun Wu wrote:
> Excerpts from Yuya Nishihara's message of 2016-10-04 00:29:09 +0900:
> > On Mon, 3 Oct 2016 15:39:24 +0100, Jun Wu wrote:
> > > Excerpts from Yuya Nishihara's message of 2016-10-03 21:59:02 +0900:
> > > > Regarding this, I was thinking about 'extensions.<name>:enabled' syntax so
> > > > users (or sysadmins) can define a set of conditionally-enabled extensions
> > > > globally.
> > > > 
> > > >   [extensions]
> > > >   rebase =
> > > >   topic = /path/to/topic.py
> > > >   topic:enabled = False
> > > > 
> > > > chg daemon will import all extensions listed in ~/.hgrc. And if :enabled = True
> > > > is flagged by repo/.hg/hgrc, ui/reposetup() will be run.
> > > 
> > > This may make the implementation more complex and fragile. One area that chg
> > > currently cannot handle 100% correct is things like "-r bundles", shared
> > > repo, or inferrepo - confighash may mismatch forever because of differences
> > > between chg's config loading logic and the non-chg one. If that happens, chg
> > > may redirect forever.
> > 
> > Isn't the goal of this series to get rid of the confighash?
> 
> Yes. "confighash" will only contain sensitive environment variables like
> PYTHONPATH, LD_PRELOAD etc. ui.config won't affect confighash.

Nice. :)

> > > Because of the above two reasons, I prefer no uisetup for all extensions. It
> > > leads to a simpler and safer implementation.
> > 
> > Yep. No ui/reposetup() in the main server process. My idea is how to tell
> > chg server to pre-import extensions which can't be enabled globally.
> 
> That has been taken care of in patch 4, which I haven't sent yet. [1]
> 
> [1]: https://bitbucket.org/quark-zju/hg-draft/commits/51278775

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.