(+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. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel