-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Use workspace inheritance to abstract some packages metadata #9896
Conversation
This might be a good time to start using workspace inheritance! It would also be useful for license, repository, and other fields. |
That's an excellent call. Can we do that here and update the title + description to match? |
Authors were removed in #2654 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much nicer :) A bit annoying that we have to list "please we do actually want to use that" in all of the child crates, but if that's required there's nothing we can do.
I don't think using workspace inheritance for metadata is that interesting, as it's very verbose and doesn't really solve a problem. #6089 was doing pretty much that and was rejected. |
Just for context, I just did this PR because I wanted to have author data when listing all the dependency licenses with Cargo license. I found it strange that other crates have an author, but Bevy doesn't. Example: instead of something like
|
@mockersf, I think that if there are problems with the version metadata, we can set it manually. However, I don't see any reason why we shouldn't use workspace inheritance for something like the repository field. |
Objective
Solution
Use workspace inheritance to define the next fields:
I also added some keywords and categories, and included the macro repositories as members of the workspace.