Rust extensions: the next step

[Yuya Nishihara]

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.