Open shepmaster opened 5 years ago
my multi-crate deploy is now in an unfinished state
Incidentally, it would be really nice if cargo publish --dry-run
could somehow work for multi-crate publishes without publishing the dependencies.
There are a number of open issues for better validation: rust-lang/cargo#4300 rust-lang/cargo#5554 rust-lang/cargo#4377 rust-lang/crates.io#7250.
I think there has been some previous talk about sharing some validation code. I'm of the opinion that it would be a good idea to create a new library for this purpose, which contains only very basic validation functions. I think it is unlikely Cargo and crates.io could share something like the Manifest
definition, so it would probably just need to contain a few free functions and constants. It would also only validate very basic elements. For example, it would not validate category names, or crates.io's list of reserved crate names (which lives in a database).
Perhaps those limitations means it would not have much value. I would like to hear from others what they think.
I did a survey of some of the validation done between the two. Of course cargo does lots of other validation that isn't applicable here (profiles, dependencies, etc.).
I think it is feasible to create a new package that the two projects share, that would have about 5 to 10 free functions defining some validation. I'm still not sure if it will provide significant maintenance improvements (weighed against the maintenance burden of publishing and coordinating a new package). There are also a lot of judgement calls listed below, as to how Cargo would treat the extra restrictions. Adding a warning to the publish/package step doesn't really help much (just makes --dry-run
a little better, and feedback a little sooner). Happy to hear any thoughts here.
|
cargo |
crates.io |
Shareability |
Package name |
|
|
Difficult to share the extra crates.io validations. Not sure why restrictions are in database and not in code. This needs careful consideration. |
version |
|
|
Not likely shareable, part of type definition. |
authors |
No restrictions. |
|
Possibly shareable as a publish/package warning? |
description |
|
|
Keep as-is? See https://github.com/rust-lang/cargo/issues/4840 |
homepage, documentation, repository |
|
|
Possibly shareable as a publish/package warning or error? |
readme |
|
|
N/A |
keyword |
No restrictions. |
|
Possibly shareable as a publish/package warning or error? |
keywords |
No restrictions. |
|
Possibly shareable as a publish/package warning or error? |
category |
No restrictions. |
|
Unlikely shareable. Maybe address with future “dry run” publish API? |
categories |
No restrictions. |
|
Possibly shareable as a publish/package warning or error? |
license |
|
|
Possibly shareable as a publish/package warning or error? See also https://github.com/rust-lang/cargo/issues/2039 for discussion on license parsing. Also https://github.com/rust-lang/cargo/issues/3540 |
Feature name |
|
|
Possibly shareable, as a Cargo.toml hard error? Depends on if packages must be ASCII? |
Feature list entry |
|
|
Same as above. |
Dependencies |
|
|
Unlikely to be shareable. |
Badges |
|
|
Maybe shareable? Warn on publish/package? Wouldn’t really improve things except for `—dry-run`. See also https://github.com/rust-lang/cargo/issues/3576 |
Sharing some thoughts from rust-lang/cargo#7256 :
cargo publish --dry-run
before a more public release.cargo publish --dry-run
can do a test upload to, would solve that problem, ensuring we're always validating against the latest rules, and moot the need for refactoring logic out into a new library to boot.
After extensive testing locally and in CI, I finally went to publish to crates.io and received the error:
This is unfortunate as my multi-crate deploy is now in an unfinished state and I have to burn through a version number.
(@carols10cents told me to file this here)