Oxidizing Mercurial (Using Rust)

[Gregory Szorc]

On Mon, Dec 4, 2017 at 1:35 AM, David Demelier <markand at malikania.fr> wrote:

> On Sun, Dec 03, 2017 at 11:31:54PM -0800, Gregory Szorc wrote:
> > A number of people have expressed an interest in using Rust in Mercurial.
> > (Facebook is already using Rust for the Mononoke Mercurial server and
> > extensions in the hg-experimental repo. But we still don't have any Rust
> in
> > core.)
>
> Rust is a good language, it is a good idea to get out from python in the
> future.
>
> > I recently typed up https://www.mercurial-scm.org/wiki/OxidationPlan. It
> > attempts to capture everything concerning using Rust with core
> Mercurial. A
> > lot of the content was discussed at the 4.4 Sprint. But other content is
> > new. So even if you attended the Sprint, it is probably worth reading. By
> > all means, please edit the content where it needs editing!
>
> Some notes before editing the wiki:
>
>     If hg becomes a Rust binary and we want Mercurial to be a
> self-contained
>     application, we'll need to overhaul our packaging mechanisms on all
>     operating systems.
>
> If building a rust application, one must use cargo anyway.
>
>     We could provide a self-contained archive file containing hg binary,
>     libpython27.so, and any other dependencies. We could also provide rpm,
> deb,
>     etc packages for popular distributions. These would be self-contained
> and
>     not dependent any many (any?) other packages. Our biggest concern here
> is
>     libc compatibility. That can be solved by static linking, compiling
> against
>     a sufficiently old (and compatible) libc, or providing distro-specific
>     packages.
>
> Please don't, it's the the business of a developer to write a package for
> each
> trillions of distributions out there. I would be okay to say that for
> flatpak
> but not for native package management.
>

We already have problems today getting modern versions of Mercurial on
end-user machines. Using pip for distribution helps. But I think it would
be better if we leveraged the "native" package manager. Other popular open
source projects do this by publishing deb and rpm files or by operating
full repositories that people configure (Docker and Node are examples that
come to mind). When you do this, you need to produce per-distro-version
packages to ensure compatibility. Or you can bundle dependencies and target
a wide net. Pick your poison.

I want to reiterate that the standalone packages will be (mainly) for
Mercurial's own distributions and we will not drop support for
non-standalone installations. After all, if you are a packager and control
all the dependencies, by all means have Mercurial link against the system
Python [like it does today]. The standalone distributions are about
ensuring we can get a modern Mercurial build in front of as many users as
possible with as little friction as possible.


>
> I just have one question though:
>
> Once the most priorities are rewritten in Rust, will all the rest be
> converted as well? I mean, having one day a 100% rust Mercurial?
>

At this time, I'm pretty confident saying 100% Rust Mercurial is an
anti-goal. There is just too much Python code in existence in core to say a
full port is practical. Plus we'd remove value of all the Python extensions
that have been written. A rewrite would also consume precious time that
could be spent improving existing features. I foresee the use of Rust being
deliberate and targeted for the next several years (likely low-level and
performance-sensitive operations). Who knows what the distant future holds
though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20171206/7fe14dea/attachment.html>