On Thu, 18 Oct 2018 19:15:06 +0200, Georges Racinet wrote: > On 10/18/2018 04:09 PM, Yuya Nishihara wrote: > > I expect "rustext" (or its upper layer) to be a shim over Rust-based modules > > and cexts. So if you do policy.importmod('parsers'), it will return > > cext.parsers, whereas policy.importmod('ancestor') will return > > rustext.ancestor, > > though I have no idea if there will be cext/pure.ancestor. > Yes, it's quite possible to add a new module policy this way. After all, > from mercurial.policy, it behaves in the same way as the cext package > does and the fact that we have a single shared library instead of > several ones is an implementation detail, hidden by Python's import > machinery. > > But this opens another, longer term, question: currently what I have in > mercurial.rustext.ancestor has only a fragment of what > mercurial.ancestor provides. Therefore to have mercurial.policy handle > it, we'll need either to take such partial cases into account, or decide > to translate the whole Python module in Rust. For the time being, I'm > simply doing an import and catch the error to fallback to the Python > version.
That could be handled by policy._modredirects, e.g. _modredirects = { ('rustext', 'parsers'): ('cext', 'parsers'), ('cext', 'ancestor'): ('pure', 'ancestor'), # and move pure-python implementation to pure/ancestor.py } But yeah, it will depend on the number of redirects whether doing that will make things clearer or not. We can decide that later. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel