On Sun, 17 Jun 2018 17:47:11 +0200, Boris FELD wrote: > On 15/06/2018 13:44, Yuya Nishihara wrote: > > On Fri, 15 Jun 2018 10:48:34 +0200, Boris FELD wrote: > >>> I'd rather force callers of ctx.diff() to build a diffopts object. > >> Do you see a way to solves the import cycle? > > Which one? > > + Import cycle: mercurial.obsutil -> mercurial.patch -> > mercurial.scmutil -> mercurial.obsutil > + Import cycle: mercurial.copies -> mercurial.scmutil -> > mercurial.obsutil -> mercurial.patch -> mercurial.copies > + Import cycle: mercurial.obsolete -> mercurial.obsutil -> > mercurial.patch -> mercurial.scmutil -> mercurial.obsolete
IIUC, the cycle is caused by the following function call: obsolete.createmarkers() -> obsutil.geteffectflag() -> _cmpdiff() and I think createmarkers() is more like a utility function than a storage function. So, if we had a higher-level utility module for obsolete users, which isn't imported from scmutil, maybe we can move createmarkers() and geteffectflag() to that module. We'll also have to move scmutil.cleanupnodes() to that module. <new utility module> -> scmutil / patch Another option will be just delaying the import of the patch module, and add TODO comment. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
