You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.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.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.)
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. Seecargo publishshould warn on invalid categories/keywords #4300 for details.package.categories: This is a bit harder, because the list is maintained incrates.iorepo. 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.readmeand other file paths:Need to check the existence of the file, if linked(see fix(toml): Convert warnings thatlicenceandreadmefiles 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 ofbuild.rsdoesn't get reported #13073 since we already infer the file if a "well known" name is used).package.homepageand other URLs: Perform URL validation and check URLs against the newly-implemented blacklist. (blacklist is maintain incrates.io, so this would be another index-dependent check.)features.<name>Cargo feature name validation inconsistent with crates.io #5554Banning of wildcard dependencies --dry-run does not validate dependencies #5941
See also #4840 for concerns with other registries.