Cargo: 在首次发布时要求确认某些 crate 数据

创建于 2020-11-22 · 3评论 · 资料来源: rust-lang/cargo

描述你试图解决的问题
crates.io 最常见的支持请求是删除 crates。为了避免破坏其他 crates/consumers，我们很少能遵守这些要求。请求的常见原因包括：

我想在-和_之间进行更改，或者修改我的箱子的外壳（ foo vs Foo ）。
我打错了。我现在以正确的名称发布，但想删除它以避免混淆。（我们建议他们拉出所有版本的死板条箱。）
我没有意识到作者字段自动填充了我的姓名和电子邮件地址。
我正在测试一些东西，没有人会使用这个板条箱。（他们本可以考虑使用分期，但现在为时已晚。）

描述您想要的解决方案

在发布期间， cargo可以检查 crate 之前是否已发布。如果这是第一次发布， cargo会提示用户确认各种 crate 元数据。特别是，将要求用户确认 crate 名称的准确拼写和authors的内容。应该让用户知道，一旦 crate 发布，就无法更改或删除此数据。

首次发布后，对authors的任何更改都是对Cargo.toml $ 的显式更改，因此此确认只需要发生一次。或者，作者提示可以作为cargo new的一部分来完成。

一些 crate 是通过 CI 或其他脚本发布的。为避免破坏此用例，检查和提示应仅在交互式 TTY 上发生。我们可以添加一个--yes样式参数，并在非交互式首次发布时警告该参数是否丢失，但是我认为仅交互式提示就可以涵盖绝大多数在这里遇到意外的用户。

笔记

我们可以将用户链接到配置登台注册表的说明，以涵盖上面的第 4 个要点。但是，我认为优先级应该是向用户清楚地传达 crate 名称在发布后是不可变的，并确认他们愿意共享自动生成的作者信息。

从理论上讲，替代注册表可以允许对 crate 进行重命名或变异。我认为这会打破cargo和生态系统中的许多假设。因此，我认为此检查应适用于所有注册表，但如果需要，可以针对 crates.io 进行检查。（如果我们决定将用户指向 staging，那应该只对默认 crates.io 注册表进行。）

C-feature-request Command-publish

资料来源

jtgeibel

👍10 ❤3

最有用的评论

我想这个的替代方法是 crates.io 默认“试运行”发布新的 crate，并通过电子邮件发送 crate 的发布者/所有者以确认他们想要发布？在通过 Web UI（或 API，可能）确认发布之前，可能不会将 crate 添加到索引中，并且无法下载等。这对于测试 README 或其他类似元数据的更改也很有用，而无需快速连续发布多个补丁。

不过，实现起来似乎要困难得多，所以也许这个问题的提议可以是第一步。

Mark-Simulacrum 于 2020-11-22

👍4

所有3条评论

不过，实现起来似乎要困难得多，所以也许这个问题的提议可以是第一步。

Mark-Simulacrum 于 2020-11-22

👍4

除了要求作者确认细节外，Cargo 还可以对常见错误进行检查并进行警告。

警告：箱子名称包含大写字母。 Rust crate 名称不区分大小写，并且大多数 crate 使用所有小写名称以保持一致性。

警告：箱子名称包含连字符。在代码中使用 crate 时，连字符会转换为下划线。在 crate 名称中使用连字符会导致 crate 在 crates.io 中的名称与代码中的名称不同。

等等。

Rantanen 于 2020-11-22

“试运行”发布

这让我想起了一个有趣的功能请求 rust-lang/crates.io#1515，如果有的话会很高兴。

在通过 Web UI（或 API，可能）确认发布之前，可能不会将 crate 添加到索引中，并且无法下载等。

我不认为我们对此有问题，但在某处我看到了一个建议，即 crates.io 可以允许对 crate 名称进行限时预订（能够每隔几个月手动刷新一次）。如果我们有保留名称的基础设施，那么第一次发布的特殊外壳可以在此基础上构建。我们希望保留的 crate 出现在搜索中，并有某种登录页面表明 crate 已保留或待处理。（并且保留名称可以以兼容的方式进行调整，直到第一个版本

这对于测试 README 或其他类似元数据的更改也很有用，而无需快速连续发布多个补丁。

我真的很喜欢这个想法，因为在看到我闪亮的新版本的自述文件有问题后，我肯定有几分钟发布。它超越了上面的--dry-run[=verify]和首次发布方法。用户可以使用--dry-run=pending发布，我们会将版本显示为待处理（类似于yanked ），但只有 crate 的所有者才能看到待处理的版本。特别是对于自述文件，我看到的最大问题是，当从 S3 提供服务时，它们可以被缓存（我认为目前为 1 天）。因此，我们可能需要对待处理版本进行特殊处理。

我认为这些功能可以很好地协同工作，并为增量更改提供良好的路径。我也同意目前对首次发布服务器端进行特殊封装需要大量工作。不过，我有兴趣看到所有这些选项的进一步探索。

jtgeibel 于 2020-11-25

此页面是否有帮助？

0 / 5 - 0 等级

Cargo: 在首次发布时要求确认某些 crate 数据

最有用的评论

所有3条评论

相关问题