Conflicting tokio "core" dependency

Continuing: Tokio in Integration Testing Compile Error which was closed due to inactivity.

I also have a dependency named "core". I'm not sure about the commented solution in the thread being ideal - wouldn't it be better to rename this "core" Tokio dependency? Having a "core" in the domain seems pretty common and if the conflict can't be solved in other way (?) it seems more suitable for the dependencies to choose a more specific name.

It's not Tokio dependency, it's the language core library, which is explicitly referenced from Tokio to be sure that the expected items will be imported successfully.

I meant it as a dependency used by Tokio. Next question would be whether it's realistic to rename the language's core library, or probably more meaningfully whether there's a fix for this situation that doesn't require to avoid naming dependencies in the same way?

You shouldn't have a custom dependency named core for the same reason you shouldn't have one named std.

Ok, that's really unfortunate. I have fairly large project that has been using an internal "core" dependency for a while. Just got this, when adding tokio (for a test).

The core library is even more fundamental than std and it is not going to be renamed. You should rename your own core library to something else. Lot's of macros out there are going to reference core for various things.

3 Likes

In fact, I am quite surprised that Rust even lets you name your dependency core in the first place.

Okay, I stand by this being a bit awkward and inconvenient, but not a big deal to change my dependency's name. Thanks for the quick replies in any case.

Edit: yeah, a warning / error when naming the crate would improve this a lot.