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

Georges Racinet georges.racinet at octobus.net
Tue Apr 23 04:35:27 EDT 2019


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.racinet at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190423/2ca5c3e2/attachment.sig>


More information about the Mercurial-devel mailing list