Cargo: Ask for confirmation of certain crate data on first publish

Created on 22 Nov 2020 · 3Comments · Source: rust-lang/cargo

Describe the problem you are trying to solve
The most common support request we get for crates.io is to delete crates. To avoid breaking other crates/consumers, we can rarely comply with these requests. Common reasons for the request include:

I would like to change between - and _, or modify the casing (foo vs Foo) of my crate.
I made a typo. I've now published under the correct name, but want to delete this to avoid confusion. (We recommend they yank all versions of the dead crate.)
I did not realize that the authors field was automatically populated with my name and email address.
I was testing something out and nobody will ever use this crate. (They could have considered using staging, but it is too late now.)

Describe the solution you'd like

During a publish, cargo could check to see if the crate has been published before. If this is the first publish, cargo would prompt the user to confirm various crate metadata. In particular, the user would be asked to confirm the exact spelling of the crate name and the contents of authors. The user should be made aware that there is no way to change or remove this data once a crate is published.

After the initial publish, any changes to authors is an explicit change made to Cargo.toml so this confirmation only needs to happen once. Alternatively, the authorship prompt could be done as part of cargo new.

Some crates are published via CI or other scripts. To avoid breaking this use case, the check and prompt should only occur on an interactive TTY. We could add a --yes style argument and warn if the argument is missing for a non-interactive first-publish, however I think the interactive prompt alone would cover the vast majority of users that run into surprises here.

Notes

We could link the user to instructions for configuring the staging registry, to cover the 4th bullet point above. However, I think the priority should be on clearly communicating to the user that the crate name is immutable after a publish and confirming that they are comfortable with sharing the auto-generated authorship information.

Theoretically, alternative registries could allow crates to be renamed or mutated. I think this would break many assumptions in cargo and the ecosystem. Therefore I think this check should apply to all registries, but could be made specific to crates.io if desired. (If we decide to point users towards staging, that should only be done for the default crates.io registry.)

C-feature-request Command-publish

Source

jtgeibel

👍10 ❤3

Most helpful comment

I guess an alternative to this is for crates.io to "dry run" publish new crates by default, and email the publisher/owner of the crate to confirm that they want to publish? The crate would not be added to the index, perhaps, and not be available for download etc until the publish is confirmed through the web UI (or API, perhaps). This could also be useful for e.g. testing changes to README or other similar metadata without publishing multiple patches in quick succession.

The implementation seems much harder for that, though, so maybe this issue's proposal can be a first step.

Mark-Simulacrum on 22 Nov 2020

👍4

All 3 comments

The implementation seems much harder for that, though, so maybe this issue's proposal can be a first step.

Mark-Simulacrum on 22 Nov 2020

👍4

In addition to asking the author to confirm the details, Cargo could also implements checks for the common mistakes and warn about them.

Warning: The crate name contains upper case letters. Rust crate names are case insensitive and most crates use all lowercase names for consistency.

Warning: The crate name contains hyphens. When using the crate in code, the hyphens are converted to underscores. Using hyphens in the crate names results in the crate having a different name in crates.io than in code.

etc.

Rantanen on 22 Nov 2020

"dry run" publish

This reminds me of an interesting feature request rust-lang/crates.io#1515 that would be nice to have.

The crate would not be added to the index, perhaps, and not be available for download etc until the publish is confirmed through the web UI (or API, perhaps).

I don't think we have an issue open for this, but somewhere I saw a suggestion that crates.io could allow time limited reservation of crate names (with the ability to manually refresh it every few months). If we had the infrastructure to reserve names then special casing the first publish could build on top of that. We would want reserved crates to show up in the search and have some sort of landing page saying that the crate is reserved or pending. (And reserved names could be tweaked in compatible ways until the first version is

This could also be useful for e.g. testing changes to README or other similar metadata without publishing multiple patches in quick succession.

I really like this idea, as I definitely have a few release made minutes after seeing my shiny new release has an issue with the README. It goes beyond the --dry-run[=verify] and first-publish approaches above. Users could publish with --dry-run=pending and we would show the version as pending (similar to yanked) but only owners of the crate would be able to see the pending version. For the README in particular, the biggest issue I see is that they can be cached (I think for 1 day currently) when served from S3. So we might need to special case things for pending versions.

I think these features could work together well and provide a good path for incremental changes. I also agree that special casing the first-publish server side at the moment would take a lot of work. I would be interested in seeing all of these options explored further though.

jtgeibel on 25 Nov 2020

Was this page helpful?

0 / 5 - 0 ratings