Skip to content
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

Native Java provider appears when using REPO.bazel #158

Open
alexeagle opened this issue Sep 23, 2024 · 2 comments
Open

Native Java provider appears when using REPO.bazel #158

alexeagle opened this issue Sep 23, 2024 · 2 comments

Comments

@alexeagle
Copy link

alexeagle commented Sep 23, 2024

@fmeum (bazelbuild/bazel-gazelle#1852) and I (bazelbuild/bazel-gazelle#1917) have been trying to make the bazel-gazelle go_repository PackageInfo functional.

bazel-gazelle generates a target @some-go-package//:gazelle_generated_package_info for each package installed, you can observe this working with cquery for example:

% bazel cquery --output=starlark --starlark:expr='providers(target)["@@rules_license//rules:providers.bzl%PackageInfo"]' @com_github_spf13_cobra//:gazelle_generated_package_info
INFO: Analyzed target @@com_github_spf13_cobra//:gazelle_generated_package_info (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
struct(label = Label("@@com_github_spf13_cobra//:gazelle_generated_package_info"), package_name = "github.com/spf13/cobra", package_url = "https://github.com/spf13/cobra", package_version = "1.8.1", type = "package_info")
struct(label = Label("@@com_github_spf13_cobra//:gazelle_generated_package_info"), package_name = "github.com/spf13/cobra", package_url = "https://github.com/spf13/cobra", package_version = "1.8.1", type = "package_info")

This package info isn't attached directly to go_library targets. Rather it uses the (new?) repo() function in the REPO.bazel for that external repo (after all, every target there is licensed the same way)

https://github.com/bazelbuild/bazel-gazelle/blob/089096315dcaa0aea52e87ecc2bd6b89b531da1e/internal/go_repository.bzl#L369-L371

However when we cquery on a go_library target that may be reachable through the dep graph from a Go application:

The only relevant provider hanging from that go_library is LicenseInfo:

% bazel cquery --output=starlark --starlark:expr='providers(target).keys()' @com_github_spf13_cobra//:cobra
[
"LicenseInfo",
"@@io_bazel_rules_go//go/private:providers.bzl%GoLibrary", 
"@@io_bazel_rules_go//go/private:providers.bzl%GoSource", 
"@@io_bazel_rules_go//go/private:providers.bzl%GoArchive", 
"InstrumentedFilesInfo", 
"FileProvider", 
"FilesToRunProvider", 
"OutputGroupInfo"
]
% bazel cquery --output=starlark --starlark:expr='providers(target)["LicenseInfo"]' @com_github_spf13_cobra//:cobra             
INFO: Analyzed target @@com_github_spf13_cobra//:cobra (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
<instance of provider LicenseInfo>

LicenseInfo here is the one built-into Bazel's Java code, not the one declared in rules_license.

Does this mean the go_repository implementation needs to attach the PackageInfo to each go_library as well?

@Wyverald
Copy link
Member

An easy way to figure out whether this is a bug with REPO.bazel is to try the same with the package(default_package_metadata=...) thing in BUILD.bazel. Could you try that?

@fmeum
Copy link
Contributor

fmeum commented Sep 23, 2024

I think that this is expected, both package and repo are equivalent to setting the corresponding attribute on the rules, but that by itself doesn't result in the providers being advertised on the targets. You need to attach an aspect that forwards them from attrs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants