Skip to content
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

Cargo feature name validation inconsistent with crates.io #5554

Closed
iliekturtles opened this issue May 20, 2018 · 2 comments
Closed

Cargo feature name validation inconsistent with crates.io #5554

iliekturtles opened this issue May 20, 2018 · 2 comments
Labels
A-features Area: features — conditional compilation A-interacts-with-crates.io Area: interaction with registries C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-publish

Comments

@iliekturtles
Copy link
Contributor

See rust-lang/crates.io#1395 for original discussion. tl;dr: crates.io validation is working as desired and Cargo needs to be stricter.

Cargo's feature name validation is inconsistent with crates.io and should reject feature names that are not "mostly rust identifiers." Currently Cargo will accept feature names that are rejected by crates.io during cargo publish and cargo publish --dry-run doesn't detect the issue.

$ cargo publish
...
   Uploading uom v0.18.0 (file:///S:/uom)
error: api errors: invalid upload request: invalid value: string "1.20.0", expected a valid feature name
 containing only letters, numbers, hyphens, or underscores at line 1 column 931

Cargo should reject the feature name 1.20.0 prior to attempting to publish.

@alexcrichton alexcrichton added Command-publish C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` labels May 20, 2018
@MaulingMonkey
Copy link

Just ran into this with features named "*", "android::view::KeyEvent", etc. when publishing a set of related crates in tandem - and of course only my last crate failed to publish as a result.

Would core::Summary::new be a sane location to add more validation? I assume I'd need to pass in a Config or Shell so I can emit a warning instead of a fatal error (as that'd be a breaking change for any offline, unpublished projects)?

MaulingMonkey added a commit to MaulingMonkey/jni-bindgen that referenced this issue Aug 16, 2019
MaulingMonkey added a commit to MaulingMonkey/cargo that referenced this issue Aug 16, 2019
@ehuss ehuss added the A-features Area: features — conditional compilation label May 8, 2020
@epage epage added the A-interacts-with-crates.io Area: interaction with registries label Oct 23, 2023
@epage
Copy link
Contributor

epage commented Oct 23, 2023

Added this to #4377, closing in favor of that

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Oct 23, 2023
Dirbaio pushed a commit to Dirbaio/java-spaghetti that referenced this issue Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-features Area: features — conditional compilation A-interacts-with-crates.io Area: interaction with registries C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-publish
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants