Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

cargo publish --dry-run doesn't fail on invalid keywords #14426

Closed
woodruffw opened this issue Aug 18, 2024 · 3 comments
Closed

cargo publish --dry-run doesn't fail on invalid keywords #14426

woodruffw opened this issue Aug 18, 2024 · 3 comments
Labels
C-bug Category: bug Command-publish S-triage Status: This issue is waiting on initial triage.

Comments

@woodruffw
Copy link

Problem

First of all, thanks for maintaining cargo! I'm a very happy user.

I've noticed a case where cargo publish --dry-run completes successfully, but cargo publish will fail (for crates.io, and likely for other indices running the same stack).

In particular: if the keywords field contains an entry longer than 20 characters, crates.io will reject it. However, --dry-run reports no issue with such a keyword.

For example, the following keywords set will cause a publish failure:

keywords = ["til", "today-i-learned", "static-site-generator"]

...because the last member (static-site-generator) is 21 characters long.

The error message returned by crates.io suggests that a 20 character long keyword would also fail:

error: failed to publish to registry at https://crates.io/

Caused by:
  the remote server responded with an error (status 400 Bad Request): "static-site-generator" is an invalid keyword (keywords must have less than 20 characters)

Steps

  1. Create a new crate and fill in the metadata
  2. Add a keywords member that's longer than 20 chars
  3. Run cargo publish --dry-run and observe that it succeeds
  4. Run cargo publish and observe that it fails

Possible Solution(s)

Two possible solutions come to mind:

  1. More invasive: change cargo publish --dry-run's behavior so that these overlength keywords cause a failure with an appropriate error message. This would potentially cause overly eager error messages against other indices (i.e. other than crates.io), if those indices support longer keywords.
    • This could be made less intrusive by checking whether the index being published/dry-run against is a third-party one.
  2. Less invasive: emit a warning instead of a non-fatal error when the keyword is too long for crates.io. This will prevent unexpected breakage against other indices, while still providing more of a heads up to users.

There are probably other solutions, however!

Notes

No other notes.

Version

cargo 1.79.0 (ffa9cf99a 2024-06-03)
release: 1.79.0
commit-hash: ffa9cf99a594e59032757403d4c780b46dc2c43a
commit-date: 2024-06-03
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 22.4.0 (jammy) [64-bit]
@woodruffw woodruffw added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Aug 18, 2024
@weihanglo
Copy link
Member

Thank you for the report! This seems to be a duplicate of #2098, #3662, #4300, #4377, #14249, so closing in favor of those.

@weihanglo weihanglo closed this as not planned Won't fix, can't repro, duplicate, stale Aug 18, 2024
@weihanglo
Copy link
Member

Note that the limitations are set by a single registry (crates.io), while Cargo needs to support different registries.

@woodruffw
Copy link
Author

Note that the limitations are set by a single registry (crates.io), while Cargo needs to support different registries.

Yep, that makes sense -- I think the idea marked (2) above would address that case, or (1) provided that --dry-run can be made aware of the registry URL (which I think it should be, since it's part of the same publish subcommand).

(And thank you for triaging! Based on the set that's closed/still open, it seems like #4377 is the most immediately relevant to this piece of metadata.)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-bug Category: bug Command-publish S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants