crates.io：开发更新

2025 年 2 月 5 日 · Tobias Bieniek 代表 crates.io 团队

回顾 2024 年 7 月，我们发布了一篇关于 crates.io 持续开发的博客文章。自那时以来，我们取得了很大进展并发布了一些新功能。在这篇博客文章中，我们想向您介绍我们对 crates.io 所做的最新变更。

Crate 删除

在 RFC #3660 中，我们提出了一个新功能，允许 crate 所有者在特定条件下从 crates.io 删除他们的 crate。如果您误发了 crate 或想删除不再维护的 crate，此功能会很有用。在 RFC 于 8 月底获得所有团队成员接受后，我们便开始实现该功能。

我们创建了一个新的 API 端点 DELETE /api/v1/crates/:name，允许 crate 所有者删除其 crate，然后创建了相应的用户界面。如果您是某个 crate 的所有者，您现在可以前往 crate 页面，打开“Settings”（设置）选项卡，并在底部找到“Delete this crate”（删除此 crate）按钮。点击此按钮将带您进入一个确认页面，告知您删除操作的潜在影响以及删除 crate 需要满足的要求

Delete Page Screenshot

如上图所示，crate 只能在以下任一条件下删除：crate 发布时间少于 72 小时；或者 crate 只有一个所有者，且该 crate 自发布以来每个月的下载次数少于 500 次，并且 crates.io 上没有其他 crate 依赖于它。

设立这些要求是为了防止滥用删除功能，并确保社区广泛使用的 crate 不会被意外删除。如果您对此功能有任何反馈，请告知我们！

OpenAPI 描述

假期期间，我们开始尝试为 crates.io API 生成 OpenAPI 描述。这是社区的一个长期需求，我们很高兴地宣布，现在可以在 https://crates.io/api/openapi.json 找到一个实验性的 OpenAPI 描述！

请注意，这仍被视为工作进行中 (work-in-progress) 状态，例如，端点的稳定性保证尚未记录，响应模式也尚未完全文档化。

您可以在例如 https://petstore.swagger.io/ 的 Swagger UI 中查看 OpenAPI 描述，只需在顶部的输入字段中输入 https://crates.io/api/openapi.json 即可。由于在与 crates.io 本身相同的域上运行查看器存在安全顾虑，我们目前决定不自行提供查看器。如果未来有足够的需求，我们可能会重新考虑是否在专门的子域上提供它。

Swagger UI Screenshot

OpenAPI 描述是由 utoipa crate 生成的，这是一个可以与 axum Web 框架集成的工具，可以自动为您所有的端点生成 OpenAPI 描述。我们要感谢 Juha Kukkonen 在此工具上做出的出色工作！

支持表单和“举报 Crate”按钮

由于 crates.io 团队规模较小且大部分由志愿者组成，我们没有能力手动监控所有发布。因此，我们依赖于您，即 Rust 社区，帮助我们发现恶意 crate 和用户。为了让您更容易举报可疑 crate，我们在所有 crate 页面上添加了“Report Crate”（举报 Crate）按钮。如果您遇到认为恶意或违反行为准则或我们使用政策的 crate，您现在可以点击“Report Crate”按钮并填写出现的表单。这将向 crates.io 团队发送一封电子邮件，然后团队将审查该 crate 并在必要时采取适当行动。感谢大部分工作由 crates.io 团队成员 @eth3lbert 完成。

如果您在使用支持表单或“Report Crate”（举报 Crate）按钮时遇到任何问题，请告知我们。如果您不想使用表单，也可以随时直接发送电子邮件至 help@crates.io 与我们联系。

发布通知

我们增加了一项新功能，当您的 crate 发布新版本时，您可以接收电子邮件通知。这对于检测未经授权的 crate 发布或仅仅跟踪团队其他成员的发布情况都很有用。

Publish Notification Screenshot

此功能是社区提出的另一个长期存在的功能请求，我们很高兴终于实现了它。如果您不想接收发布通知，您可以前往 crates.io 上的账户设置并禁用这些通知。

其他事项

这些是过去几个月 crates.io 上一些更显而易见的变更，但“幕后”也发生了很多事情。

  • RFC #3691 已开放并被接受，以在 crates.io 上实现“Trusted Publishing”（信任发布）支持，类似于其他已采用此模式的生态系统。这将允许您在 crates.io 上指定允许哪个仓库/系统发布您的 crate 的新版本，让您可以从 CI 系统发布 crate，而无需再处理 API token。

  • 与上述内容稍有关联：在 crates.io 上创建的 API token 默认在 90 天后过期。不过，仍然可以禁用过期或选择其他过期时长。

  • crates.io 团队是最早使用 diesel 数据库访问库的项目之一，但由于它只支持同步执行，这在我们的代码库中有点不便，尤其是我们在不久前迁移到 axum 后，代码库正日益转向异步方向。diesel 的维护者 Georg Semmler 做了大量工作，使得以异步方式使用 diesel 成为可能，由此产生了 diesel-async 库。过去几个月，我们逐步将 crates.io 迁移到 diesel-async 查询，这使我们能够利用 diesel-async 内部的查询流水线，从而使我们的一些 API 端点性能提升了 10-15%。感谢 Georg 在这些 crate 上的工作！

  • 每当您发布新版本或 yank/unyank 现有版本时，都需要更新一些东西。我们的内部数据库会立即更新，然后我们在后台工作任务中同步稀疏和 git 索引。以前，对大量版本进行 yank 或 unyank 操作时，每个操作都会排队一个同步后台任务。现在我们实现了冗余后台任务的自动去重，这使得我们的后台工作更加高效。

  • 上周刚刚合并的最后一个重要的内部变更是关于我们前端代码的测试。过去我们使用一个叫做 Mirage 的工具来实现我们 API 的模拟版本，这使得我们无需启动完整的后端服务器即可运行前端测试套件。不幸的是，Mirage 近期的维护状况迫使我们寻找替代方案，我们很高兴地报告，我们现在已完全迁移到“行业标准 API 模拟”包 msw。如果您想了解更多信息，可以在这个“小型”迁移 Pull Request 中找到详细信息。

反馈

希望您喜欢这次关于 crates.io 开发进度的更新。如果您有任何反馈或问题，请通过 Zulip 或 GitHub 告知我们。我们总是乐于倾听您的意见并期待您的反馈！