gdk-sys Cairo Dependency about gdk

[GuillaumeGomez]

The problem is that crates.io and cargo don't allow a crates to have a dependency inside the project. We didn't have the choice on this one.

[jashephe]

Huh. Can we file a bug upstream about this? Or was there some justification for why this isn't possible?

[GuillaumeGomez]

I asked about that to @acrichto on the irc, he replied that if a library needs a dependency, that dependency has to declared on crates.io, or something similar. It's late and I'm tired. ^^' I advise you to ask him the question directly, it'll be better and you'll have more details.

[gkoz]

You can use git-repo to make this problem go away. There will be a cargo override out of the box.

[GuillaumeGomez]

@gkoz: I don't remember why we didn't choose this solution. Well, I'll see that tomorrow.

[gkoz]

@GuillaumeGomez I'm not sure what you mean by choosing or not. This is mostly how you manage your own working copy. This tool has helped me manage various branches across multiple repos and not go crazy.

[gkoz]

Also, path dependencies seem to actually be allowed: https://github.com/sfackler/rust-openssl/blob/master/openssl/Cargo.toml#L22

[jashephe]

I thought I had seen something like that somewhere. I don't see why that wouldn't work in our case. Is there any reason why we wouldn't want to do that?

[GuillaumeGomez]

@jashephe: That's what we wanted to do at first, the command cargo publish didn't allow it, that's all.

[gkoz]

@GuillaumeGomez you may want to ask sfackler how he managed it. At the very least you could just strip out the path line with sed in the process of publishing while keeping it in the git.

[GuillaumeGomez]

@gkoz: I will, please remind it to me, I might forget otherwise...

[gkoz]

This post makes me think that it should just work if you do it exactly like

[dependencies.blahblah]
path = "../blahblah"
version = "x.y.z"

The blahblah package does have to already be registered on crates.

[GuillaumeGomez]

Hum... That seems a lot to update for just a sub-dependency...

[gkoz]

We probably don't need to publish a new version because of this, as it only affects the git checkouts.

[GuillaumeGomez]

Maybe we should add an explanation on this error in the README ?

[gkoz]

You don't want to alter the Cargo.tomls? Dunno, using the path seems to be idiomatic and expected so explaining the error may not help a lot.

[GuillaumeGomez]

I like the fact that *-sys are in an independant crate. So I don't really know what solution might fit better here...

[gkoz]

The openssl example above is exactly like that -- two crates in one repo, there's just a bit different directory structure.

[gkoz]

We probably can't do anything about this because only the current crate would see the path dependency while the others might still link to the same crate from crates leading to confusing errors like expected 'glib::types::Type' found 'glib::types::Type'.
We may have to make it clearer that the only supported way of using crates from git is to override all of the repos.

This may call for creating a crates branch used for publishing with the "crates.io" Cargo.toml version while the master branch would use the git dependencies. At the time of publishing new commits from the master would be merged into that branch.

[GuillaumeGomez]

@gkoz: The big come back of the crates branch !

[jashephe]

Does openssl not have this problem? Or do they just not care?

[gkoz]

@GuillaumeGomez this is a little different from tracking nightlies and stable separately, because we don't expect any conflicts when merging from master. The workflow would be: merge from master, bump the version, cargo publish.

@jashephe openssl doesn't have five repos each with a sys crate.

[gkoz]

It seems, we have a satisfactory crate publishing process now.