根据依赖关系关闭默认功能答案

【问题标题】：Turn off default-features in dependency of dependency根据依赖关系关闭默认功能
【发布时间】：2018-02-09 03:44:18
【问题描述】：

我有一个依赖链，最终依赖于可选一个已弃用的库。具体来说，我想使用间接依赖于 rustc-serialize 的 nalgebra，如下所示：

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 文件以引用所有本地依赖项，这很有效，但如果可能的话，我想要一种更易于维护的方式来做到这一点。

【问题讨论】：

标签： rust rust-cargo

【解决方案1】：

作为H2O states，这是不可能的，但请查看他们的答案以获得一个好的临时解决方法，以使事情再次正常运行。我想讨论一下为什么它不应该是可能的，以及长期的解决办法是什么。

一般来说，您无法判断 crate 使用依赖项的目的。 alga 完全有可能在内部使用 num-complex 的 rustc-serialize 功能。

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

要么你最终能够向项目提交 PR 以改善每个人的案例，要么你会明白为什么你认为可选的实际上不是。

【讨论】：

“添加一个选择加入到 rustc-serialize 的功能”你的意思是选择退出 rustc-serialize 吗？
@beardc 不，功能旨在添加。 crate 应该具有启用附加功能的特性，但它们也可以具有默认特性集。您可以使 rustc-serialize 成为可选依赖项，然后将其添加到默认功能中以保持向后兼容性。该库的未来重大更改版本可能会将其从默认功能中删除。然后你会进入下一个级别，禁用默认功能，添加库需要的功能，然后重复。

【解决方案2】：

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

但是，使用此部分，您可以使您的解决方法更加简洁。只需 fork num-complex 并从默认值中删除 rustc-serialize 功能。使用 cargo-patch 提供你的叉子，如下所示：

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

这样，您的 fork 将在依赖链中一直使用，而无需单独更改每个 crate。

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

【讨论】：