Turn off default-features in dependency of dependency

Question

I have a chain of dependencies that end in depending optionally on a deprecated library. Concretely, I want to use nalgebra which depends indirectly on rustc-serialize as follows:

nalgebra -> alga -> num-complex -> (optional default) rustc-serialize

I can list the num-complex dependency in my Cargo.toml file and turn off the optional rustc-serialize dependency (num-complex = { version = "0.1.42", default-features = false }), but is there a way to turn off this option all the way up the chain in Cargo.toml?

I have tried an alternative of cloning each of these and manipulating the local copies’ Cargo.toml file to refer to all the local dependencies, which works, but I would like a more maintainable way to do this if possible.

Answer 1

As H2O states, this is not possible, but check their answer for a good temporary workaround to get things working again. I want to discuss why it should not be possible and what the long-term fix is.

In general, you cannot tell what a crate uses a dependency for. It's completely possible that alga makes use of the rustc-serialize functionality of num-complex internally.

The correct thing to do is to track the dependency chain upwards. Go to each project and add a feature that opts-in to the rustc-serialize functionality of its direct dependents. You would also add the rustc-serialize feature to the default features to maintain backwards compatibility.

Either you will end up being able to submit a PR to the project to improve everyone's case, or you will understand why what you think is optional actually isn't.

Answer 2

I am fairly certain that this is not currently possible. I looked into doing this with Cargo's [patch] section but it looks like you can't actually specify features in the patch section but can only overwrite the path or git url of a given dependency.

Using this section you could, however, make your workaround a bit neater. Just fork num-complex and remove the rustc-serialize feature from the defaults. Using cargo-patch supply your fork like this:

[patch.crates-io]
num-complex = { git = "https://github.com/your-github-name/num-complex.git" }

That way your fork will be used all the way down in the dependency chain without having to change each crate individually.

As I alluded to earlier, specifying default-features = false in this section doesn't seem to do anything. From looking at Cargo's code I don't think this is a bug, just a lack of a feature or a design decision. (After all, messing with dependencies like this is not really a great idea in the general case).