Packages, crate, crate.io duplicate name issue with mDNS in Cargo.toml

help
1

Hi there guys,

this is my first post :slight_smile: so far I like rust, though tough thing to learn ....

My problem is that there exist 2 mdns packages,
first in crate io (https://crates.io/crates/mdns, Dylan McKay)
second is also mdns in (https://github.com/plietar/rust-mdns, Paul Lietar)

Maybe I actually don't need both, I wanted to search for other "devices/services" (which works well with the mdns in crateIO - by Dylan McKay) and I found an example (not tried yet) to register myself to be found (which the plietar rust-mdns seems to be capable of exactly that)...
Goal is: (I want several clients, which decide themselves by certain rules, who will be the only master in the end - collecting all data from everyone else).

But that is not the current issue (only if you can give me a hint about how to use other implementations or something else like mDNS to do what I want).

I simply cannot use both "mdns" in cargo .toml!
How about people using same names, in other locations than crate .io etc. e.g. "timers, timer,Timers,"... by "time" people have to get quite inventive to find good names - what about discontinued projects ... ?

How can we resolve that? I read something about changing crate naming, but Cargo .toml, at the highest level, does not seem to be convincable to support that.
I tried [dependencies.origmdns] to try to rename but in the end the package name is the important name.

 [dependencies]
 ...
 mdns = "*"        # for mDNS

 [dependencies.mdns]
 crate = {git = "https://github.com/plietar/rust-mdns"}
 version = "*"

Thank you guys, every help is appreciated

1 Like
2

Neither of those crates seem to really be updated, but this is what I would do:

  • Take the one you want and work on it yourself :confused:. I had an issue with the FTP crate, and even if I knew nothing about it, the codebase was so small that fixing it up wasn't a big deal.
    Fork it, fix it and commit a PR.

  • OR, clone the mDNS crate that's on github on your computer and change its name in its Cargo.toml:

[package]
name = "mdns_plietar"

Then you can change the import in you project to be:

[dependencies]
mdns = "*"
mdns_plietar = { path = "path/to/crate" }

Rust's naming follows conventions and naming of the subject. If the given subject include a timer, it will be called timer. A cat is a cat.
When you use more than one Crate that have the same name, you can simply use the complete name:

let path = std::path::Path::new();
let path_from_ftp = ftp::path::Path::new();

(This is a rough example of what I mean, you cannot import both path here)
Yes, the ftp_path could be named ftp_path, but ultimately, the crate is already named ftp.

1 Like
3

The best would be to ask plietar/rust-mdns to rename.

You could split your project into multiple crates within a workspace:

[dependencies]
my_sub_crate = {path = "./sub_crate"}

and use one mnds in the top-level crate, and another mdns in the my_sub_crate. In the sub crate you can do pub use mdns as mdns_other.

4

You could split your project into multiple crates

...yikes!

clone the mDNS crate [...] and change its name

...double yikes!

I think what people are really trying to say is that there is currently no solution to this problem. Which is unfortunate, considering how it would appear that the majority of cargo's infrastructure is already built to support multiple crates with the same name (since the full dependency tree may include multiple versions of a crate).

(@kornel's suggestion is not bad though if you're not going to publish your crate. If you do publish it, then that stub will also get published)

2 Likes
5

I believe this is a current problem which will eventually be fixed when https://github.com/rust-lang/rfcs/pull/2126 is implemented.

The RFC there includes an option in Cargo.toml alias = "..." under any dependency to change the name passed to rustc. I'm not sure if/when this will be implemented, but it would solve this.

Not a solution yet, but there have been discussions which include this before, and may lead to something!

1 Like
6

Hi all repliers,

thanks for the hints and the latest answer from @daboross, so it seems to be in the list and going to be fixed sometime, somehow. Since this was not a pressing issue yet (I could look at other details before), I hope this RFC will be accepted and implemented, and the other tips might lead to temporary solutions. :slight_smile:
Thanks a lot

1 Like