chg and uisetup

[Jun Wu]

Excerpts from Yuya Nishihara's message of 2016-07-13 00:03:03 +0900:
> On Tue, 12 Jul 2016 15:38:16 +0100, Jun Wu wrote:
> > 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.
> 
> I think they can also be delayed until fork().

Yes. But I don't think that's a clean solution as you have to patch all
the places.

And we have to hash [extensions] anyway, because they can point to different
files:

  exta =
  exta = /path/a.py

I don't think assuming extensions are reload-safe is a good idea.
 
> > 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).
> 
> I'd rather add new option, e.g. "hg serve --cmdserver chgunix --stage preload",
> and set flags to req object. But it will require a hack to parse command
> options at early stage.
>
> Either way, we can start with req flags?
> 
>   $ cat > chg-serve
>   req = dispatch.request(sys.argv[1:])
>   req.do_not_setup_extensions = True
>   dispatch.dispatch(req)

I think this is cleaner than introducing another earlyopt. Especially
because the option does not make much sense to other commands.