On Wed, 10 Aug 2016 15:04:06 +0100, Jun Wu wrote: > Excerpts from Yuya Nishihara's message of 2016-08-10 22:55:26 +0900: > > On Wed, 10 Aug 2016 14:42:52 +0100, Jun Wu wrote: > > > Excerpts from Yuya Nishihara's message of 2016-08-10 21:01:25 +0900: > > > > The code and docstring look good, but did you try using this function? > > > > I suspect it would create an import cycle. > > > > > > I tried it using debugshell before sending and it looked okay. I didn't > > > see > > > cycles? > > > > Suppose the next patch will import dispatch.py from worker.py, > > test-check-module-imports.t will report the following error: > > > > + Import cycle: mercurial.dispatch -> mercurial.hg -> mercurial.merge -> > > mercurial.worker -> mercurial.dispatch > > + Import cycle: mercurial.commands -> mercurial.merge -> mercurial.worker > > -> mercurial.dispatch -> mercurial.commands > > + Import cycle: mercurial.bundlerepo -> mercurial.localrepo -> > > mercurial.merge -> mercurial.worker -> mercurial.dispatch -> mercurial.hg > > -> mercurial.bundlerepo > > It could be solved by importing in the method instead of globally. > commandserver.py already has: "from . import dispatch # avoid cycle"
Well, that is considered a bad pattern. commandserver (and subrepo) can't easily avoid import cycles because they send requests back to their upper layers. There are inherently cycles. But, your callcatch() could be moved to utility layer except for a few parts which are tightly bound to command handling. And worker.py won't need these parts. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
