[PATCH 1 of 8] rust-hglib: import the latest version and update URLs

[Gregory Szorc]

On Mon, Apr 2, 2018 at 5:53 PM, Kevin Bullock <
kbullock+mercurial at ringworld.org> wrote:

> > On Apr 1, 2018, at 13:53, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> >
> > On Sun, Apr 1, 2018 at 4:14 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> > # HG changeset patch
> > # User Kevin Bullock <kbullock at ringworld.org>
> > # Date 1522477348 -32400
> > #      Sat Mar 31 15:22:28 2018 +0900
> > # Node ID 9e25c96124d51e11022b0ce64783f5f333ede7fb
> > # Parent  2ed180117f7658d0cbf6a1ece20944465c55c947
> > rust-hglib: import the latest version and update URLs
> >
> > Queued parts 1-3 because vendoring rust-hglib has been talked about and
> agreed upon IIRC.
>
> Hmm, it has? Have we talked about vendoring other hglibs (c-hglib,
> python-hglib)?
>
> I recall talking about consolidating them onto m-s.o. If we decide to
> vendor them into the hg repo I think we should talk more about source
> layout first, and start w/python-hglib.
>
> That being said, I'm excited to see interest around rust-hglib!
>

I could be mistaken.

Obviously since I queued this, I have no problems taking the hglib clients
into the main repo. I'm also fine putting rust-hglib on another repo on
m-s.o/repo.

We know we want to rewrite chg in Rust. That will presumably use
rust-hglib. I think it is easier to have the library vendored. But with
Cargo, it doesn't matter too much: it will fetch dependencies easily
enough. That being said, we've punted on vendoring Rust dependencies for
the moment because Rust support is so young and we're not shipping anything
relying on Rust. But I reckon we will eventually vendor all Rust
dependencies so builds don't have to go to the Internet and can therefore
be reliable and deterministic over time. That means we'll vendor rust-hglib
into the main repo at some point. The question is whether that vendored
copy will be the canonical copy or a read-only vendored version. Since
these client libraries are maintained by the official project, I think it
makes sense to put them in the main repo.

If we proceed with vendoring the client libraries, I don't think we need to
start with python-hglib. Unlike rust-hglib, I don't foresee a use of
python-hglib in the main project. So there's less justification for
vendoring python-hglib than rust-hglib. We should be talking about
rust-hglib and ignore python-hglib (unless we want to put them all in the
same place in the repo - but that's a bikeshed and we can always move files
around later if we need to).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20180402/b79091f4/attachment.html>