Open proppy opened 7 months ago
@aiuto is that something that's already supported?
/cc @cdleary
I'm not sure if this is a bug report or just highlighting a different problem.
gather_licenses_info should capture all license_info()
and package_info()
instances in BUILD files from external repositories. So for XLS you do have a license declaration at https://github.com/google/xls/blob/a9333b2b662701ecac457070eae37829467539ae/BUILD#L39
but it has no licenses_kinds
. If I fix the source to be
license(
name = "license",
package_name = "xls",
license_kinds = ["@rules_license//licenses/spdx:Apache-2.0"],
)
I would expect that to show up in the JSON, and it does for me. So far so good.
As far as the query goes: I'm not sure what the intent is, so let's parse it back to the minimal.
bazelisk query 'deps(//xls/dslx:interpreter_main)' | grep @rules_l
This gets the license declaration, but with --notool_deps
, I don't see it. That feels like a bazel bug.
The bigger problem is for modules which do not have those declarations. Most of the importers used by workspace resolution or bzlmod do not splice in a package_info()
, so we know nothing. The workaround is to dump the tree created with gather_licenses_info
to JSON, then merge with the lockfiles for the various langauges. This was working for Bazel's own build, until we switched to bzlmod for the build. The lock file labels changed and broke the linkage. It should be easy to fix. Alas, this is only for the java maven lockfile, so all other languages still need work.
What are you expecting from the query?
Expected Behavior
gather_licenses_info.bzl
should also gather license from external packages (fetched thruWORKSPACE
orBzlmod
).Actual Behavior
gather_licenses_info.bzl
only gathers license from in-tree project sources and vendored dependencies.Steps to Reproduce the Problem
Specifications
bazel 6.4.0
Linux penguin 6.1.64-09049-g010fe86d9eae #1 SMP PREEMPT_DYNAMIC Thu, 1 Feb 2024 01:25:43 +0000 x86_64 GNU/Linuxw