remove unnecessary dependencies

[vsuryamurthy]

Hello,

I came across some unnecessary dependencies in each crate. These dependencies are however used in other crates (or) indirectly pulled into the crate.
In this PR, I used re_viewer, as an example, to show the unnecessary dependencies. I am wondering if there is a reason why these dependencies are kept as it is. Based on your thoughts, we can see how to proceed with the other crates.

[emilk]

Hi, and thanks for your PR!

It is very easy to forget to remove a crate once the code relying on it is gone, and I think that's what have happened here.

In the cases where something else is going on we should have a clarifying comment about it.

[vsuryamurthy]

Hi, and thanks for your PR!

It is very easy to forget to remove a crate once the code relying on it is gone, and I think that's what have happened here.

In the cases where something else is going on we should have a clarifying comment about it.

I completely agree. It does not change much in the sense that it is pulled indirectly. However it is cleaner. I see more such unused dependencies over the entire set of crates.

[emilk]

Feel free to clean up further!

[vsuryamurthy]

I removed more dependencies. Seems like this is it!

[emilk]

Nice! Are you using cargo-udeps to find these?

[vsuryamurthy]

I use cargo machete, basically what cargo-udeps uses under the hood.
There are more dependencies that cargo machete shows actually but those are either internal ones or looks like they are used.

[vsuryamurthy]

@emilk I will be on a break until the end of the week. You can decide what the next steps are with this PR!
P.s: The check fail is not my fault (I guess!)
P.s.s: I was wrong about cargo machete being used under the hood of cargo udeps. It is a different tool but much faster.

[emilk]

P.s: The check fail is not my fault (I guess!)

I think you need to update the Cargo.lock file, e.g. with cargo update --workspace

[vsuryamurthy]

Yep yep, I see I missed that!

[emilk]

Thank you!