On Thu, May 28, 2020 at 11:22 AM Augie Fackler <r...@durin42.com> wrote:
> > > > On May 28, 2020, at 10:10, Pierre-Yves David < > pierre-yves.da...@ens-lyon.org> wrote: > > > > We plan to start sending patches to build a minimal Rust executable > capable of fulfilling "some" operations to "some" extend. The idea is to > start small by building a tiny tool that: > > > > * focuses on usage inside script/prompt (where having a different > executable for some special action is fine), > > * explicitly only support a tiny subset of commands/flags, > > * help getting more building blocks in the `hg-core` crate, > > * respect the `hg` command line for everything it supports (to make it a > good base for something bigger). > > * is not called `hg` since it is not fully compatible with hg, yet > (maybe rhg ? or fhg ?) > > * last, but not least, help our new developer Antoine Cezar to get > familiar with the Mercurial internals and Rust code. > > > > In practice, here are the current plans for the first batch: > > > > 0) ignore configs (and extensions) for now, > > 1) crash (with a specific return code) if anything unknown is seen, > > 2) implement the following basic operations (in this order): > > * hg root [it gets us a basic executable] > > * hg files [it gets us requirement checking and dirstate reading] > > * hg files --rev REV [it gets us basic read-only revlog support] > > * hg cat --rev REV [it gets us full revlog support (eg: fn cache and > co)] > > > > Once this is done, we probably make further plans (eg: config parsing, > basic revspec support, more commands,… who knows) > > > > > > What do you think? > > I think this makes a lot of sense. I can see it used in two ways: > > 1) We've often talked about a `hg buildshellprompthelper` command (name is > bad, please figure out a better one) that could emit a shell function to > efficiently and supportedly emit things people want in their prompt, and > then depending on what was requested we could use a native-code helper > binary instead of the full `hg`) > > 2) The "PyOxidizer delegating binary" thing that Martin mentioned. > > I worry a little bit around the margins of novel storage formats etc and > how we support those, but erroring out for now is probably adequate. > My assumption is the end state of any work in this area will be a native [Rust] binary that: a) Is capable of servicing an `hg` command without starting a Python interpreter b) Is capable of acting as a command server and client c) Starts a Python interpreter and dispatches to Python code when pure Rust code paths don't exist or are unwanted d) Eventually becomes the `hg` in some (all?) distributions of Mercurial I question whether it is worth building out one-off binaries if we assume this will be the end state. I think we should: 1. Use `pyoxidizer init-rust-project` to create a skeleton for a Rust executable project. Say in `rust/hgcli` 2. Hook up a `pyoxidizer.bzl` so it can run the Python Mercurial that we have today 3. Teach `run-tests.py`, `Makefile`, etc to build and use the new executable in a turnkey manner 4. Start hacking up `main()` to inject Rust code before the Python interpreter is started (via environment variables, minimal argument parsing, or whatever) Alternatively, we can inject PyOxidizer later, after we have a stub executable. But I suspect it will be drastically easier to do from the beginning, as that approach forces you to think about the interactions between Rust and Python sooner rather than later. Plus, the sooner this happens, the sooner it benefits end-users. Having chg baked into the executable so it is easier to use will be a huge win for users. If we were talking about a science experiment, I'd be inclined to start simple now. But Mercurial will be around for years, so why accrue technical debt against something that is part of the project's long-term vision. PyOxidizer should hopefully be stable enough that its presence doesn't hinder progress that much. Although I may need to land some features in PyOxidizer to help with e.g. reducing build times and not making iterative development as painful. Also, Eden's public source code has GPL'd Rust sources for things like configuration file and argument parsing. See e.g. https://phab.mercurial-scm.org/D7575. Their implementations largely conform with Mercurial's and we can probably get a Rust binary doing everything up to command dispatch in pure Rust with only a few days of effort.
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
