-
Notifications
You must be signed in to change notification settings - Fork 28
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
Create ADD_PKG_MGR.md #142
base: main
Are you sure you want to change the base?
Conversation
Needs some discussion with @mzeren-vmw about whether this is the shape we want to commit to, vs. having a `package_info` rule as well.
See also: bazelbuild/bazel#22403, which asks for a way of attaching license info to a specific target (which we will need for |
load("@rules_license//rules:license.bzl", "license") | ||
|
||
package( | ||
default_package_metadata = [":license"], |
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.
If people are doing the integration, we should take the same opportunity to add package_info
rules to pull package names and versions into the BUILD file in a uniform way.
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.
This looks mostly reasonable to me.
My only question is the name of the .md file. ADD_PKG_MGR could be interpreted as "how to add a package manager" rather than the intent, which is the (too) long winded "How to integrate rules_license into package managers.
Does |
We can declare multiple |
Having now implemented this for
|
Ping @tonyaiuto this is the thing preventing me from volunteering to update many of the language rulesets |
Allows package manager implementations like rules_jvm_external to begin declaring the licenses or other metadata about third-party packages they fetch and add to the dependency graph.
Needs some discussion with @mzeren-vmw about whether this is the shape we want to commit to, vs. having a
package_info
rule as well.