Compilation issue when using the same depenency once locally and once via crates.io

help
1

Hello, I am running into a weird compilation error that I could boil down to this.

I have a workspace with two crates, call them DependsLocally and DependsRemotely which both depend on the actix crate version 0.12.0. It's not really important that this is about actix, but this is my shared dependency.

For the DependsLocally library I have checked out the actix repo at tag 0.12.0 and stored it in a local folder on my machine. The Cargo.toml looks like this:

[dependencies]
actix = {path = "/path/to/local/actix/actix"}

whereas for the other crate, DependsRemotely, I have added the actix dependency via crates.io, like so:

[dependencies]
actix = "0.12.0"

This nonsensical example is only to illustrate my problem. Now what happens is during compilation:

error[E0277]: the trait bound `Pong: actix::Message` is not satisfied

the compiler complains that a specific trait bound from the actix crate is not satisfied. Why does it do that? Those crates have literally the same code...

also: how can I make this work, meaning have one local actix that I am using (and modifying minimally) and have the dependencies work with the remote version from crates.io.

2

The two instances of the actix crate, even if they’re the same code and the same version, will still be considered different crates when they come from different places (crates.io vs. a path dependency). This means that the Message trait from one of these actix crates will be a different trait than the Message trait from the other actix crate.

So in this case, your Pong type will be implementing actix::Message from one actix crate, but you’re trying to use it in a context where something that implements the other actix::Message trait is expected.

Now, how to resolve this… one relevant question is: why do you have a local copy of the actix crate at all when it’s “literally the same code” as the crates.io version? Why not just use the crates.io dependency everywhere? If you do need some local modifications of the actix crate, then you can achieve consistent usage of that modified version throughout your local crates and even remote dependencies that depend on actix by using [patch.crates-io] in your Cargo.toml.

1 Like
3

Thanks for the explanation, I had assumed something like this. Yes, the example is silly but I need some modifications on the actix crate that haven't made it into the released version yet. Those modifications would not have impacted the traits, but I see now how that does not matter.

I'll look into the patch feature and see if I can make it work. I might have more questions :slight_smile:

4

turns out I really do have more questions. Can I use patch.crates-io to override the actix dependency inside other dependencies? To me it looks like that patch section only applies to the opened Cargo.toml but not recursively to the dependencies of dependencies.

So what I am asking is: can I force the crates I depend on to use my actix crate instead of theirs? (without having to edit their Cargo.toml files)

EDIT Sorry, I was wrong. This seems to do what I want. I just needed to add the patch section to the Cargo.toml of my workspace rather than the individual crates of my workspace

5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.