On 4/21/19 12:21 PM, Yuya Nishihara wrote:
> On Tue, 16 Apr 2019 21:26:17 +0200, Georges Racinet wrote:
>> # HG changeset patch
>> # User Georges Racinet <georges.raci...@octobus.net>
>> # Date 1555441784 -7200
>> # Tue Apr 16 21:09:44 2019 +0200
>> # Node ID 410396d5eca793a1b8cf9ee8ba7bce466e9be3c0
>> # Parent a362b0b95e42c8f7d46d7e3a0eb4cc531fa5f2d6
>> # EXP-Topic rust-crates.io
>> rust: published the three extension crates to crates.io
> I think it's good idea to reserve the crate names, but...
>
>> --- a/rust/Cargo.toml Fri Apr 05 14:35:33 2019 +0200
>> +++ b/rust/Cargo.toml Tue Apr 16 21:09:44 2019 +0200
>> @@ -1,3 +1,6 @@
>> [workspace]
>> members = ["hg-core", "hg-direct-ffi", "hg-cpython"]
>> exclude = ["chg", "hgcli"]
>> +
>> +[patch.crates-io]
>> +hg-core = {path = "hg-core"}
>> \ No newline at end of file
> Nit: ^^^^^^^^^^^^^^^^^^^^^^^^
>
>> [dependencies]
>> -hg-core = { path = "../hg-core" }
>> -libc = '*'
>> +hg-core = "0.0.1"
> Is it worth specifying local crates by version number and patching it in
> place?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. 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. Of course, we could just content ourselves with the name reservation, but I'd be glad to make one step further. Regards, -- Georges Racinet https://octobus.net GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
