chg and uisetup

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2016-07-09 23:07:06 +0900:
> On Fri, 8 Jul 2016 11:31:37 +0100, Jun Wu wrote:
> > 1. Do not run uisetup / extsetup before forking
> > 
> >    Assume that:
> >    1. importing (do not run *setup) an extension module is side-effect free
> >    2. ui/extsetups are fast (seems true by my benchmark)
> >
> >    We can just import all potentially needed modules in chgserver.
> 
> These assumptions seem legit.

Things like "@command" and "@templatekeyword" are a blocker to this
approach. Therefore confighash will remain and I still want to solve the
uisetup issue.

> >    This looks like a big arch change, and a big step backward because a lot
> >    of code can be removed, and is against the preforking model. But it is
> >    doable within the current framework by providing a blank hgrc, and call
> >    extensions.load() during chgserver startup. The command would be like:
> > 
> >       cd /; HGRCPATH=blankhgrc hg serve ... --pre-import some-hgext/*.py
> 
> I don't like the proposed command interface, but I like the big picture of
> this idea. It will allow us to get rid of complicated ui hacks at the cost
> of designing a dedicated dispatcher for chg.
> 
> Maybe we'll need a PoC implementation to make sure that we can take this
> approach.

I'm thinking about a different entry point other than "hg serve".
It would be somewhere like "contrib/chg/chg-serve" or whatever name. The
main difference is it gets a chance to remove features from "dispatch.py":

  - do not run ui/extsetups
  - do not construct the repo object
  - do not parse [alias]

What do you think? I feel optimistic as it solves some of the most annoying
issues and can remove some hacks (no need to hash [alias] and [extdiff], no
need to walkconfig).