Closed thesayyn closed 1 year ago
Adding a dependency incurs maintenance costs. There's gazelle dependency in skylib, that we'd rather see removed. rules_proto is one repository that potentially a lot of other repositories will depend on, so we need to be as cautious as possible.
This is a dev dependency, which should not be required by users at all, so I don't see why not. Keeping bzl_library targets up to date is more tedious work than having a few lines of dev dependency, as engineers usually forget about updating bzl_library targets and have to circle back to fix them which is not ergonomic.
I'd rather have a command that just fixes the bzl_library targets for me than figure out what labels I need to use in order to fix the bzl_library targets.
Heres some repositories that I know do this which I love working with;
https://github.com/bazel-contrib/rules_jvm/blob/e384e30182b3f36ef2f324943e06567c7577af79/MODULE.bazel#L14-L15 https://github.com/bazelbuild/rules_dotnet/blob/03ac96aac3b8a3cfc28830b317f72a33e74e6949/internal_deps.bzl#L49-L56 https://github.com/bazel-contrib/rules-template/blob/84fcf22b77716fcfa925a2013404e819d07b84b0/MODULE.bazel#L13 https://github.com/bazel-contrib/rules_jvm/blob/e384e30182b3f36ef2f324943e06567c7577af79/MODULE.bazel#L14-L15
One thing we can do here as @alexeagle suggested is switch to bzlmod by default so we add dev-dependencies to only MODULE.bazel to keep the diff small and maintainable.
I think we can drop this to start with, and we'll explain the problem with bzl_library
in OSS rulesets later.
This introduces gazelle to allow us to generate bzl and proto targets automatically. We should also introduce a CI check to assert BUILD files are up to date.