chg and uisetup

[Yuya Nishihara]

On Tue, 12 Jul 2016 16:54:28 +0100, Jun Wu wrote:
> 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:  
> > > 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.

They can be executed at 2nd dispatch() like ui/extsetup().

 1. load extension modules at first dispatch(), but don't setup them
 2. fork()
 3. commandserver.server.runcommand() -> dispatch()
 4. run ui/extsetup and register commands, templates, etc. if there are
    preloaded and enabled extensions

> And we have to hash [extensions] anyway, because they can point to different
> files:
> 
>   exta =
>   exta = /path/a.py

/path/a.py can be loaded after fork(), and replace preloaded "exta", which
isn't set up yet.

Perhaps we'll need data structure like this:

 extname: (path, module, not_set_up_yet)

> > > 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.

Yeah, new options shouldn't be global. It should be an option of the serve
command, and that's why we'll need a hack to parse it.