-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ask for confirmation of certain crate data on first publish #8883
Comments
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. |
In addition to asking the author to confirm the details, Cargo could also implements checks for the common mistakes and warn about them.
etc. |
This reminds me of an interesting feature request rust-lang/crates.io#1515 that would be nice to have.
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
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 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. |
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:
-
and_
, or modify the casing (foo
vsFoo
) of my crate.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 ofauthors
. 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 toCargo.toml
so this confirmation only needs to happen once. Alternatively, the authorship prompt could be done as part ofcargo 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.)The text was updated successfully, but these errors were encountered: