<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 4, 2017 at 1:35 AM, David Demelier <span dir="ltr"><<a href="mailto:markand@malikania.fr" target="_blank">markand@malikania.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Dec 03, 2017 at 11:31:54PM -0800, Gregory Szorc wrote:<br>
> A number of people have expressed an interest in using Rust in Mercurial.<br>
> (Facebook is already using Rust for the Mononoke Mercurial server and<br>
> extensions in the hg-experimental repo. But we still don't have any Rust in<br>
> core.)<br>
<br>
</span>Rust is a good language, it is a good idea to get out from python in the<br>
future.<br>
<span><br>
> I recently typed up <a href="https://www.mercurial-scm.org/wiki/OxidationPlan" rel="noreferrer" target="_blank">https://www.mercurial-scm.org/<wbr>wiki/OxidationPlan</a>. It<br>
> attempts to capture everything concerning using Rust with core Mercurial. A<br>
> lot of the content was discussed at the 4.4 Sprint. But other content is<br>
> new. So even if you attended the Sprint, it is probably worth reading. By<br>
> all means, please edit the content where it needs editing!<br>
<br>
</span>Some notes before editing the wiki:<br>
<br>
    If hg becomes a Rust binary and we want Mercurial to be a self-contained<br>
    application, we'll need to overhaul our packaging mechanisms on all<br>
    operating systems.<br>
<br>
If building a rust application, one must use cargo anyway.<br>
<br>
    We could provide a self-contained archive file containing hg binary,<br>
    libpython27.so, and any other dependencies. We could also provide rpm, deb,<br>
    etc packages for popular distributions. These would be self-contained and<br>
    not dependent any many (any?) other packages. Our biggest concern here is<br>
    libc compatibility. That can be solved by static linking, compiling against<br>
    a sufficiently old (and compatible) libc, or providing distro-specific<br>
    packages.<br>
<br>
Please don't, it's the the business of a developer to write a package for each<br>
trillions of distributions out there. I would be okay to say that for flatpak<br>
but not for native package management.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I just have one question though:<br>
<br>
Once the most priorities are rewritten in Rust, will all the rest be<br>
converted as well? I mean, having one day a 100% rust Mercurial?<br></blockquote><div><br></div><div>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.<br></div></div></div></div>