Expand manifest validation for all settings

[behnam]

There are some practical difficulties arising from the fact that manifest files are not always validated. I want to collect such cases, so we can improve the user experience, specially for newbies, by showing warnings about bad manifest entries, as soon as possible.

One important fact here is that we almost never want to throw an error on invalid entries, because it will affect forward-compatibility: would make many future changes non-backward-compatible.

Some Examples

I think almost every config item can have some sort of validation. This list only presents possible validation methods for different types of values.

• package.version: The version is not already present (Fail fast when package version is already published #3662).

• package.keywords: Having invalid keywords strings only surface during packaging/publishing. See cargo publish should warn on invalid categories/keywords #4300 for details.

• package.categories: This is a bit harder, because the list is maintained in crates.io repo. But, like any other index-related data, it can be fetched, cached, and checked against.

• package.include, package.exclude, workspace.exclude, workspace.members: These are configs with pattern-matching and warning on invalid patterns can help users track down packaging issues easier and faster, and make changes in those areas easier. (See Change Cargo include/exclude rules to gitignore patterns #4268)

• package.readme and other file paths: Need to check the existence of the file, if linked (see fix(toml): Convert warnings that licence and readme files do not exist into errors #13921). In addition, we can also warn on missing the config, if a best-guess file is present (similar to Misspelling of build.rs doesn't get reported #13073 since we already infer the file if a "well known" name is used).

• package.homepage and other URLs: Perform URL validation and check URLs against the newly-implemented blacklist. (blacklist is maintain in crates.io, so this would be another index-dependent check.)

• features.<name> Cargo feature name validation inconsistent with crates.io #5554

• Banning of wildcard dependencies --dry-run does not validate dependencies #5941

[behnam]

cc @alexcrichton, @carols10cents

[alexcrichton]

Seems plausible to me! All this validation happens on crates.io though which I'd prefer to not duplicate, although we can perhaps do simple things like validate homepage is a URL locally for sure. (also agreed with warnings-for-now)

[behnam]

Some more background and my rational for this proposal: The other day, for a new release for UNIC, I was updating a dozen of manifests, mostly their metadata. Since it's not vise to package/publish with dirty repository, I had to commit after each publish error, and try publishing again. This resulted in a handful of commits just catching all the small nits from the publish command, like "don't use space in the keywords list".

Agreed that we better have one source of truth. However, I also believe we can benefit a lot by moving this one source of truth to a library that can be used in client side (cargo CLI, clippy, etc), as well as server side (crates.io, etc). I call it the cargo-manifest crate, which I think should spin out of cargo proper (which hosts all the CLIs, etc). This would allow cargo, crates.io and third-party CLIs to share the same manifest read/validation logic, without the need to have cargo execution details imported as dependency.

What do you think?

[Boddlnagg]

rust-lang/crates.io#7250 is also related to this (see point 2.)