我有一连串的依赖关系，这些依赖关系最终取决于可选的不赞成使用的库。具体来说，我想使用nalgebra，它间接依赖于rustc-serialize，如下所示：

nalgebra-> alga-> num-complex->(可选默认值)rustc-serialize

我可以在我的Cargo.toml文件中列出num-complex依赖项，并关闭可选的rustc-serialize依赖项(num-complex = { version ="0.1.42", default-features = false })，但是有一种方法可以在Cargo链中一直关闭此选项.toml？

我尝试了一种替代方法，即克隆每个副本并处理本地副本。 Cargo.toml文件可引用所有本地依赖项，这是可行的，但我希望有一种更可维护的方式来做到这一点。

正如H2O所述，这是不可能的，但是请检查他们的答案以找到一个好的临时解决方法，以使事情再次起作用。我想讨论为什么它不可能以及长期解决方案是什么。

通常，您无法确定一个板条箱使用了什么依赖项。海藻完全有可能在内部使用num-complex的rustc-serialize功能。

正确的做法是向上跟踪依赖关系链。转至每个项目并添加一个功能，以选择其直接依赖项的rustc-serialize功能。您还可以将rustc-serialize功能添加到默认功能中，以保持向后兼容性。

您要么最终可以向项目提交PR，以改善每个人的情况，要么您就会明白为什么您认为可选的实际上不是必需的。

我相当确定这是当前不可能的。我考虑使用Cargo的部分进行此操作，但看起来您实际上无法在patch部分中指定功能，但只能覆盖给定依赖项的路径或git url。

使用此部分，您可以使解决方法更整洁。只需派生num-complex并从默认值中删除rustc-serialize功能。使用货补为您的叉子供应，如下所示：

这样一来，您的fork将在依赖链中被完全使用，而不必单独更改每个板条箱。

正如我前面提到的，

在本节中指定default-features = false似乎没有任何作用。通过查看Cargo的代码，我认为这不是错误，只是缺少功能或设计决策。 (毕竟，在一般情况下，弄乱这样的依赖关系并不是一个好主意)。