[PATCH 1 of 2] rust: published the three extension crates to crates.io

[Yuya Nishihara]

(+CC Mike Hommey as he might know Debian packaging issues)

On Tue, 23 Apr 2019 10:35:27 +0200, Georges Racinet wrote:
> As far as I understand, it's necessary for all uploaded crates to
> specify at least some version restriction, and path-only dependencies
> aren't accepted.
> 
> https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies
> 
> I tried the { path = "../hg-core", version = "0.0.1" } variant (seems to
> work indeed), but I find the workspace solution cleaner (since we
> already got one) and I'm more confident about its platform independence.
> 
> > I think the whole point of monorepo-style layout is to get rid of the
> > complexity of the dependency management. So long as the rust hg-* crates
> > are merely internal modules, I don't think we have to care about versioning
> > of these crates.
> 
> Besides third party dependencies to hg-core or even hg-cpython
> appearing, here's a reason for them not being purely internal:
> downstream packagers may need to rely on the crates.io version as per
> their policies or tooling capabilities.

Do we plan to provide a Rust library? I'm not against to if that's worth
the cost. I just feel it's too early.

> If I understood well what Debian packagers told me about it, it is
> mandatory for inclusion in Debian, meaning that if a Rust-enhanced
> Mercurial were to enter Debian, the crates would be taken from
> crates.io. Anything in Debian testing can be backported to stable.
> Therefore, Debian's release cycle being close to an end means that such
> a scenario will be possible again quite soon.

Any idea how firefox is packaged? I think the situation is quite similar,
in-repository Rust crates + other.