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

login
register
mail settings
Submitter Georges Racinet
Date April 16, 2019, 7:26 p.m.
Message ID <410396d5eca793a1b8cf.1555442777@purity.tombe.racinet.fr>
Download mbox | patch
Permalink /patch/39666/
State New
Headers show

Comments

Georges Racinet - April 16, 2019, 7:26 p.m.
# HG changeset patch
# User Georges Racinet <georges.racinet@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

These are the contents of the first publication for
`hg-core`, `hg-cpython` and direct `hg-direct-ffi`, done with
the sarting point '0.0.1' version.
This version has been chosen to be actually lower than the one
declared up to now in the crates manifests.

In the workspace (rust/Cargo.toml), there's an override so that
if building from the whole source, the local hg-core gets selected.

We will have to select a version policy for the upcoming releases,
with the obvious option to have Rust versions equal to the general
Mercurial version, however partial they are.

It should be noted though that the development version must stay
be higher than the latest that be found on crates.io and that satisfies
the rules in Cargo.lock.
(see https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#testing-a-bugfix)
Georges Racinet - April 16, 2019, 9:12 p.m.
Hi,

On 4/16/19 9:26 PM, Georges Racinet wrote:
> # HG changeset patch
> # User Georges Racinet <georges.racinet@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
>
> These are the contents of the first publication for
> `hg-core`, `hg-cpython` and direct `hg-direct-ffi`, done with
> the sarting point '0.0.1' version.

In order to be really explicit, yes, I've uloaded them:

    https://crates.io/crates/hg-core

    https://crates.io/crates/hg-cpython

    https://crates.io/crates/hg-direct-ffi

Of course I'm all willing to give ownership on these crates to the
project, but that requires a GitHub Organization (only for
authentication). Reference: (ref:
https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner).
I don't feel like I should be the one to create one out of the blue, but
I could and would invite the whole steering committee if I did.

The upload is of course out of band, but I found it somewhat appropriate
to submit the commits below, because it makes the involved files really
explicit, and persists the related explanations in a strong way. Also,
this was the occasion to fill the required fields (License etc).

> This version has been chosen to be actually lower than the one
> declared up to now in the crates manifests.
>
> In the workspace (rust/Cargo.toml), there's an override so that
> if building from the whole source, the local hg-core gets selected.
>
> We will have to select a version policy for the upcoming releases,
> with the obvious option to have Rust versions equal to the general
> Mercurial version, however partial they are.

I think the time between the freeze / branch cut and actual release
would probably be the appropriate one to come up with such a scheme
(more than right now anyway). I'll be ready to help if needed.

In any case, I suppose it's better whatever the actual version number is
to have it consistent in the release tag.

Cheers,

>
> It should be noted though that the development version must stay
> be higher than the latest that be found on crates.io and that satisfies
> the rules in Cargo.lock.
> (see https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#testing-a-bugfix)
>
> diff -r a362b0b95e42 -r 410396d5eca7 rust/Cargo.lock
> --- a/rust/Cargo.lock	Fri Apr 05 14:35:33 2019 +0200
> +++ b/rust/Cargo.lock	Tue Apr 16 21:09:44 2019 +0200
> @@ -47,7 +47,7 @@
>  
>  [[package]]
>  name = "hg-core"
> -version = "0.1.0"
> +version = "0.0.1"
>  dependencies = [
>   "rand 0.6.5 (registry+https://github.com/rust-lang/crates.io-index)",
>   "rand_pcg 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
> @@ -55,10 +55,10 @@
>  
>  [[package]]
>  name = "hg-cpython"
> -version = "0.1.0"
> +version = "0.0.1"
>  dependencies = [
>   "cpython 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
> - "hg-core 0.1.0",
> + "hg-core 0.0.1",
>   "libc 0.2.45 (registry+https://github.com/rust-lang/crates.io-index)",
>   "python27-sys 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
>   "python3-sys 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
> @@ -68,7 +68,7 @@
>  name = "hgdirectffi"
>  version = "0.1.0"
>  dependencies = [
> - "hg-core 0.1.0",
> + "hg-core 0.0.1",
>   "libc 0.2.45 (registry+https://github.com/rust-lang/crates.io-index)",
>  ]
>  
> diff -r a362b0b95e42 -r 410396d5eca7 rust/Cargo.toml
> --- 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
> diff -r a362b0b95e42 -r 410396d5eca7 rust/hg-core/Cargo.toml
> --- a/rust/hg-core/Cargo.toml	Fri Apr 05 14:35:33 2019 +0200
> +++ b/rust/hg-core/Cargo.toml	Tue Apr 16 21:09:44 2019 +0200
> @@ -1,12 +1,15 @@
>  [package]
>  name = "hg-core"
> -version = "0.1.0"
> -authors = ["Georges Racinet <gracinet@anybox.fr>"]
> +version = "0.0.1"
> +authors = ["Georges Racinet <georges.racinett@octobus.net>"]
>  description = "Mercurial pure Rust core library, with no assumption on Python bindings (FFI)"
> +license = "GPL-2.0-or-later"
> +homepage = "https://mercurial-scm.org"
> +repository = "https://www.mercurial-scm.org/repo/hg"
>  
>  [lib]
>  name = "hg"
>  
>  [dev-dependencies]
> -rand = "*"
> -rand_pcg = "*"
> +rand = "~0.6"
> +rand_pcg = "~0.1"
> diff -r a362b0b95e42 -r 410396d5eca7 rust/hg-cpython/Cargo.toml
> --- a/rust/hg-cpython/Cargo.toml	Fri Apr 05 14:35:33 2019 +0200
> +++ b/rust/hg-cpython/Cargo.toml	Tue Apr 16 21:09:44 2019 +0200
> @@ -1,7 +1,11 @@
>  [package]
>  name = "hg-cpython"
> -version = "0.1.0"
> -authors = ["Georges Racinet <gracinet@anybox.fr>"]
> +version = "0.0.1"
> +authors = ["Georges Racinet <georges.racinett@octobus.net>"]
> +description = "Mercurial Python bindings using the cpython crate"
> +license = "GPL-2.0-or-later"
> +homepage = "https://mercurial-scm.org"
> +repository = "https://www.mercurial-scm.org/repo/hg"
>  
>  [lib]
>  name='rusthg'
> @@ -18,17 +22,17 @@
>  python3 = ["python3-sys", "cpython/python3-sys", "cpython/extension-module"]
>  
>  [dependencies]
> -hg-core = { path = "../hg-core" }
> -libc = '*'
> +hg-core = "0.0.1"
> +libc = "^0.2"
>  
>  [dependencies.cpython]
> -version = "*"
> +version = "~0.2.1"
>  default-features = false
>  
>  [dependencies.python27-sys]
> -version = "0.2.1"
> +version = "~0.2.1"
>  optional = true
>  
>  [dependencies.python3-sys]
> -version = "0.2.1"
> +version = "~0.2.1"
>  optional = true
> diff -r a362b0b95e42 -r 410396d5eca7 rust/hg-direct-ffi/Cargo.toml
> --- a/rust/hg-direct-ffi/Cargo.toml	Fri Apr 05 14:35:33 2019 +0200
> +++ b/rust/hg-direct-ffi/Cargo.toml	Tue Apr 16 21:09:44 2019 +0200
> @@ -2,11 +2,14 @@
>  name = "hgdirectffi"
>  version = "0.1.0"
>  authors = ["Georges Racinet <gracinet@anybox.fr>"]
Do we have a ritualized formulation for authorship, such as "and
Mercurial development community" ?
> -description = "Low level Python bindings for hg-core, going through existing C extensions"
> +description = "Mercurial low level Python bindings, going through existing C extensions"
> +license = "GPL-2.0-or-later"
> +homepage = "https://mercurial-scm.org"
> +repository = "https://www.mercurial-scm.org/repo/hg"
>  
>  [dependencies]
> -libc = "*"
> -hg-core = { path = "../hg-core" }
> +libc = "^0.2"
> +hg-core = "0.0.1"
>  
>  [lib]
>  crate-type = ["staticlib"]
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Yuya Nishihara - April 21, 2019, 10:21 a.m.
On Tue, 16 Apr 2019 21:26:17 +0200, Georges Racinet wrote:
> # HG changeset patch
> # User Georges Racinet <georges.racinet@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?

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.
Georges Racinet - April 23, 2019, 8:35 a.m.
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@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,
Yuya Nishihara - April 23, 2019, 12:36 p.m.
(+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.
Georges Racinet - April 25, 2019, 1:11 p.m.
On 4/23/19 2:36 PM, Yuya Nishihara wrote:
>> 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.
>
Well actually, yes, at least for hg-core.

For instance, this work of Valentin (added Cc) on a Rust hg status would
probably benefit to cargo-depend on hg-core soon :
https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-February/128768.html

Another case where I'd imagine it to be useful that hg-core version on
crates.io would be consistent with released hg versions is for third
party extensions. I've already taken a serious look at treedirstate, and
would like to bring it to the core at some point. I'm not sure how I'll
proceed, but being able in intermediate steps to simply depend onto the
hg-core from crates.io would be an interesting option.

In general, I agree that our Rust code is not stable enough for people
to rely it without a strong coordination with us, and the version number
should reflect that, but such strong coordination cases do exist.

About the version number, I reached a conclusion (could elaborate on it
later on):

    Mercurial x.y.z would correspond to hg-core 0.xy.z  (example: 4.9.1
-> 0.49.1)

I understand all this is probably a complication in the release process,
though, and I'm ready to help if needed. Maybe I could upload crates
corresponding to Mercurial 5.0 manually ? I don't think it would harm
the ecosystem, I'd just have to submit a bump of the version numbers in
our source tree after that.

In any case, I don't want to overwork the release team, and I'd
understand if you'd would postpone all of this for the 5.1 timeframe,
hoping we could sort this out IRL during the sprint. I would certainly
put it on the agenda.

Best,
Yuya Nishihara - April 28, 2019, 9:16 a.m.
On Thu, 25 Apr 2019 15:11:23 +0200, Georges Racinet wrote:
> On 4/23/19 2:36 PM, Yuya Nishihara wrote:
> >> 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.
> >
> Well actually, yes, at least for hg-core.
> 
> For instance, this work of Valentin (added Cc) on a Rust hg status would
> probably benefit to cargo-depend on hg-core soon :
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-February/128768.html
> 
> Another case where I'd imagine it to be useful that hg-core version on
> crates.io would be consistent with released hg versions is for third
> party extensions. I've already taken a serious look at treedirstate, and
> would like to bring it to the core at some point. I'm not sure how I'll
> proceed, but being able in intermediate steps to simply depend onto the
> hg-core from crates.io would be an interesting option.

Okay, then, how about releasing only the hg-core crate? IIRC, the cpython
bridge connects to Mercurial over C API, which means there's no guarantee
that the released crate will work flawlessly with the system Mercurial.
And the direct-ffi should be removed hopefully soon.

> In general, I agree that our Rust code is not stable enough for people
> to rely it without a strong coordination with us, and the version number
> should reflect that, but such strong coordination cases do exist.
> 
> About the version number, I reached a conclusion (could elaborate on it
> later on):
> 
>     Mercurial x.y.z would correspond to hg-core 0.xy.z  (example: 4.9.1
> -> 0.49.1)

Sure it seems less scary than hg-core x.y.z (which means we can't change
the API until hg-core x+1.0.0.) I don't know if the crate version should
look similar to the Mercurial version.

> I understand all this is probably a complication in the release process,
> though, and I'm ready to help if needed. Maybe I could upload crates
> corresponding to Mercurial 5.0 manually ? I don't think it would harm
> the ecosystem, I'd just have to submit a bump of the version numbers in
> our source tree after that.
> 
> In any case, I don't want to overwork the release team, and I'd
> understand if you'd would postpone all of this for the 5.1 timeframe,
> hoping we could sort this out IRL during the sprint. I would certainly
> put it on the agenda.
Augie Fackler - May 15, 2019, 6:25 p.m.
> On Apr 16, 2019, at 17:12, Georges Racinet <georges.racinet@octobus.net> wrote:
> 
> Of course I'm all willing to give ownership on these crates to the
> project, but that requires a GitHub Organization (only for
> authentication). Reference: (ref:
> https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner).
> I don't feel like I should be the one to create one out of the blue, but
> I could and would invite the whole steering committee if I did.

https://github.com/mercurial-scm is now a thing, and I've sent you an invitation. I ticked the box to require two-factor auth for all org members, hopefully that doesn't make life difficult.

Patch

diff -r a362b0b95e42 -r 410396d5eca7 rust/Cargo.lock
--- a/rust/Cargo.lock	Fri Apr 05 14:35:33 2019 +0200
+++ b/rust/Cargo.lock	Tue Apr 16 21:09:44 2019 +0200
@@ -47,7 +47,7 @@ 
 
 [[package]]
 name = "hg-core"
-version = "0.1.0"
+version = "0.0.1"
 dependencies = [
  "rand 0.6.5 (registry+https://github.com/rust-lang/crates.io-index)",
  "rand_pcg 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
@@ -55,10 +55,10 @@ 
 
 [[package]]
 name = "hg-cpython"
-version = "0.1.0"
+version = "0.0.1"
 dependencies = [
  "cpython 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
- "hg-core 0.1.0",
+ "hg-core 0.0.1",
  "libc 0.2.45 (registry+https://github.com/rust-lang/crates.io-index)",
  "python27-sys 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
  "python3-sys 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
@@ -68,7 +68,7 @@ 
 name = "hgdirectffi"
 version = "0.1.0"
 dependencies = [
- "hg-core 0.1.0",
+ "hg-core 0.0.1",
  "libc 0.2.45 (registry+https://github.com/rust-lang/crates.io-index)",
 ]
 
diff -r a362b0b95e42 -r 410396d5eca7 rust/Cargo.toml
--- 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
diff -r a362b0b95e42 -r 410396d5eca7 rust/hg-core/Cargo.toml
--- a/rust/hg-core/Cargo.toml	Fri Apr 05 14:35:33 2019 +0200
+++ b/rust/hg-core/Cargo.toml	Tue Apr 16 21:09:44 2019 +0200
@@ -1,12 +1,15 @@ 
 [package]
 name = "hg-core"
-version = "0.1.0"
-authors = ["Georges Racinet <gracinet@anybox.fr>"]
+version = "0.0.1"
+authors = ["Georges Racinet <georges.racinett@octobus.net>"]
 description = "Mercurial pure Rust core library, with no assumption on Python bindings (FFI)"
+license = "GPL-2.0-or-later"
+homepage = "https://mercurial-scm.org"
+repository = "https://www.mercurial-scm.org/repo/hg"
 
 [lib]
 name = "hg"
 
 [dev-dependencies]
-rand = "*"
-rand_pcg = "*"
+rand = "~0.6"
+rand_pcg = "~0.1"
diff -r a362b0b95e42 -r 410396d5eca7 rust/hg-cpython/Cargo.toml
--- a/rust/hg-cpython/Cargo.toml	Fri Apr 05 14:35:33 2019 +0200
+++ b/rust/hg-cpython/Cargo.toml	Tue Apr 16 21:09:44 2019 +0200
@@ -1,7 +1,11 @@ 
 [package]
 name = "hg-cpython"
-version = "0.1.0"
-authors = ["Georges Racinet <gracinet@anybox.fr>"]
+version = "0.0.1"
+authors = ["Georges Racinet <georges.racinett@octobus.net>"]
+description = "Mercurial Python bindings using the cpython crate"
+license = "GPL-2.0-or-later"
+homepage = "https://mercurial-scm.org"
+repository = "https://www.mercurial-scm.org/repo/hg"
 
 [lib]
 name='rusthg'
@@ -18,17 +22,17 @@ 
 python3 = ["python3-sys", "cpython/python3-sys", "cpython/extension-module"]
 
 [dependencies]
-hg-core = { path = "../hg-core" }
-libc = '*'
+hg-core = "0.0.1"
+libc = "^0.2"
 
 [dependencies.cpython]
-version = "*"
+version = "~0.2.1"
 default-features = false
 
 [dependencies.python27-sys]
-version = "0.2.1"
+version = "~0.2.1"
 optional = true
 
 [dependencies.python3-sys]
-version = "0.2.1"
+version = "~0.2.1"
 optional = true
diff -r a362b0b95e42 -r 410396d5eca7 rust/hg-direct-ffi/Cargo.toml
--- a/rust/hg-direct-ffi/Cargo.toml	Fri Apr 05 14:35:33 2019 +0200
+++ b/rust/hg-direct-ffi/Cargo.toml	Tue Apr 16 21:09:44 2019 +0200
@@ -2,11 +2,14 @@ 
 name = "hgdirectffi"
 version = "0.1.0"
 authors = ["Georges Racinet <gracinet@anybox.fr>"]
-description = "Low level Python bindings for hg-core, going through existing C extensions"
+description = "Mercurial low level Python bindings, going through existing C extensions"
+license = "GPL-2.0-or-later"
+homepage = "https://mercurial-scm.org"
+repository = "https://www.mercurial-scm.org/repo/hg"
 
 [dependencies]
-libc = "*"
-hg-core = { path = "../hg-core" }
+libc = "^0.2"
+hg-core = "0.0.1"
 
 [lib]
 crate-type = ["staticlib"]