chg and uisetup
quark at fb.com
Tue Jul 12 11:54:28 EDT 2016
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
And we have to hash [extensions] anyway, because they can point to different
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
I think this is cleaner than introducing another earlyopt. Especially
because the option does not make much sense to other commands.
More information about the Mercurial-devel