Cargo dependency issue with gtk-rs

I'm trying to make some changes to 'sourceview' crate. When I clone it, it is the same version (0.8.0) as specified in my Cargo.toml, and it builds quite happily, but when I then refer to it using [patch.crates-io] and try to build my project, it gives dependency errors:

    Updating git repository `https://github.com/gtk-rs/cairo`
    Updating git repository `https://github.com/gtk-rs/gdk`
    Updating git repository `https://github.com/gtk-rs/gdk-pixbuf`
    Updating git repository `https://github.com/gtk-rs/sys`
    Updating git repository `https://github.com/gtk-rs/gio`
    Updating git repository `https://github.com/gtk-rs/glib`
    Updating git repository `https://github.com/gtk-rs/gtk`
    Updating git repository `https://github.com/gtk-rs/pango`
error: failed to select a version for `gdk-pixbuf-sys`.
    ... required by package `sourceview v0.8.0 (/mnt/old-home/austin/projects/rust/gtk/sourceview)`
    ... which is depended on by `sourceview-test v0.1.0 (/mnt/old-home/austin/projects/rust/gtk/sourceview-test)`
versions that meet the requirements `*` are: 0.9.1

the package `gdk-pixbuf-sys` links to the native library `gdk_pixbuf`, but it conflicts with a previous package which links to `gdk_pixbuf` as well:
package `gdk-pixbuf-sys v0.9.1`
    ... which is depended on by `gdk-pixbuf v0.8.0`
    ... which is depended on by `gdk v0.12.1`
    ... which is depended on by `gtk v0.8.1`
    ... which is depended on by `sourceview-test v0.1.0 (/mnt/old-home/austin/projects/rust/gtk/sourceview-test)`

failed to select a version for `gdk-pixbuf-sys` which could resolve this conflict

If I remove the [patch.crates-io] reference, my project builds fine.

I'd be most grateful for some hints on how to resolve this.

It's hard to read the message. Please wrap it in a code block markup:

```
like this
```

You ended up with two copies of gdk-pixbuf-sys, and the entire cargo project is allowed to have only one (because it's a C dependency, and C doesn't support namespacing).

One of them is probably gdk-pixbuf-sys from git, the other is gdk-pixbuf-sys from crates.io. It matters to Cargo where a create is from, and each source counts as unique. Try using patch to replace crates.io's gdk-pixbuf-sys to be the git version, or vice versa.

Many thanks for that. I added

[patch.crates-io]
gdk-pixbuf-sys = { git = "https://github.com/gtk-rs/sys" }

which fixed the problem. I then had to add another 8 crates to get round similar errors.

I now get a new error:

the trait `glib::object::IsA<gio::auto::file::File>` is not implemented for `gio::auto::file::File`

with the accompanying suggestion

note: perhaps two different versions of crate `glib` are being used?

Running cargo with --verbose revealed a rustc flag

--extern glib=~/projects/rust/gtk/sourceview-test/target/debug/deps/libglib-733b450ce73db35b.rlib

which I take to mean that a version of glib in my local copy of the sourceview tree is being used instead of the ~/.cargo one. Can you throw any light on this?

Using git dependencies will quickly make you end up with multiple versions of dependencies. If you do a cargo clean followed by cargo build, you can inspect the list of compiled dependencies to see which versions got included, and you can then try to fix the dependencies to avoid that, or you can try to force it to use certain versions using cargo's patch feature.

Now you have two copies of glib. It looks like you're going to be getting an error for every single gtk dependency, one after another, until you switch them all to git, or all to crates-io. That one git dep has split the world into two GTKs.

1 Like

... you're going to be getting an error for every single gtk dependency, one after another, until you switch them all to git, or all to crates-io.

Yes, I see what you mean (I just thought that the style of error was different for the glib case) Anyway, I just copied wholesale all the crate's dependencies into my projects, et voila! it all came right.

I must say, Cargo and sorting out dependencies seems to be the hardest part of Rust programming, closely followed by getting all the uses and mods in the right places; the actual coding is a piece of cake! :smile:

My thanks again to all who helped.