Explore ways to have more package metadata providers. #59
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi Bill. I just wanted to run this idea by you. It's not urgent. I want to hear what users say at BazelCon |
Licenses are still special because they need to go down to the license_kind, but other metadata (self-contained) providers can be gathered generically. This PR has two parallel implementations so we can explore the ramifactions of each. The early attempt was to make PackageInfo a first class element, equal to LicensesInfo in the way we recursively gather it. The problem with that approach is that it requires you to scale licenses_core.bzl with each new type. A different approach is to have a generic TransitiveMetadataInfo collector that can hold many different types of provider in it, as long as they all obey the same protocol for identifying their type. We pass a provider list to gather_licenses_info_common() to select what to include. This way, a user adding a private metadata type only needs to add a new write-json capability for their custom provider. That is still a little ugly, but at least we can share gather_licenses_info_common().
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is in support of Renaming applicable_licenses to packge_metadata. Please read that plan first for context.
Licenses are still special because they need to go down to the license_kind, but other metadata (self-contained) providers can be gathered generically. This PR has two parallel implementations so we can explore the ramifactions of each.
The early attempt was to make PackageInfo a first class element, equal to LicensesInfo in the way we recursively gather it. The problem with that approach is that it requires you to scale licenses_core.bzl with each new type.
A different approach is to have a generic TransitiveMetadataInfo collector that can hold many different types of provider in it, as long as they all obey the same protocol for identifying their type. We pass a provider list to gather_licenses_info_common() to select what to include.
This way, a user adding a private metadata type only needs to add a new write-json capability for their custom provider. That is still a little ugly, but at least we can share gather_licenses_info_common().
DO NOT SUBMIT. Work in progress. This is more of an early design review.