cargo-prune

清理 "target" 文件夹中的 crate 依赖

当 cargo update 获取一个 crate 的新版本时，这个新版本的 crate 将作为依赖项重新编译。然而，对应于上一个版本的库仍然保留在依赖文件夹中。它们通过在库名称末尾添加哈希值来区分。这使得 Travis 等构建缓存的大小增加，这并不理想，因为上传缓存既浪费空间也浪费时间。这个实用程序允许在 deps 目录中搜索重复的库，并将它们修剪到只包含所需的一小部分。

在这个点上，问题在于为什么是“一些”而不是恰好一个。这是因为考虑这种情况，我们有依赖项 A, B, C 和 D，并且它们各自内部依赖于 Z 作为依赖项之一。由于每个都依赖于 Z 的不同版本，这种状况变得复杂。例如，A 依赖于 Z-ver-x0，B 依赖于 Z-ver-x1，C 依赖于 Z-ver-x2，而 D 依赖于 Z-ver-x3。现在都需要这些依赖项。如果我们试图只保留一个 Z（可能是最新的），那么下一次构建将需要重新编译其他 3 个。这并不是我们想要的。此外，仅仅读取 Cargo.lock 文件并“猜测”保留多少，有时可能不起作用，因为某些 CI 运行 cargo clippy 之前，这可能会为 Z 创建一些其他 rlib。这仅发生在某些库中，而不是所有库中。因此，而不是找出这里可能变化的模式，我们保留所有 Zs，如果它们的时戳没有超过 2 小时的差异。这是一个常数，可以更改和重新编译。这假设在运行 cargo clippy 和 cargo test 等，之间不会超过 2 小时的差异。如果一个库非常大，并且差异超过这个时间量，则应相应地增加常数并重新编译软件包。如果 cargo prune 足够流行，并且希望我们能够通过标志或配置在运行时指定值，那么在请求之后，将更改代码并发布版本。然而，在此之前，只是保持这个简单的，用代码中定义的常数。

默认情况下，将搜索 ./target，但通过命令行参数可以指定不同的目标目录。目标目录可以具有任何复杂的层次结构 - 将递归搜索并修剪重复的库依赖项。

目前这仅适用于 .rlib 依赖项。

您需要通过 cargo 安装它（即在 Linux 等，应该在 ~/.cargo/bin/ 中）才能使其工作。

例如。

• cargo prune（如果安装到 cargo bin 目录）
• cargo prune --target some/path（如果安装到 cargo bin 目录）