-
Notifications
You must be signed in to change notification settings - Fork 181
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
Add the gazelle plugin to the distribution #400
Conversation
Is there anything else I need to do? |
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.
I think you may have removed all reviewers with write access to this repo :-)
@@ -51,3 +51,25 @@ gazelle( | |||
name = "gazelle", | |||
gazelle = ":gazelle-skylib", | |||
) | |||
|
|||
# The files needed for distribution |
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.
Would adding allow_empty
to the glob
be an alternative? It wouldnt' be error-prone in this context.
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.
According to the docs, allow_empty
defaults to True
, but I've made it explicit.
gazelle_setup.bzl
Outdated
|
||
def bazel_skylib_gazelle_plugin_setup(): | ||
go_rules_dependencies() | ||
go_register_toolchains(version = "1.17.1") |
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.
Have you tried calling this macro from a WORKSPACE
that already sets up a Go toolchain somewhere else? You might have to make running this configurable via a parameter.
If possible, also bump the version to 1.18.7
as 1.17
is out of support. 1.19
is available, but requires a relatively recent version of rules_go
.
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.
Done and done.
To avoid everyone needing to take a dep on `rules_go`, we do the following: 1. Regular Bazel users need to load `bazel_skylib_gazelle_plugin_workspace` and call that, and then `bazel_skylib_gazelle_plugin_setup` 2. `bzlmod` users need do nothing, but we now include the `rules_go` dep in the `MODULE.bazel` shipped in the release. This is fine, because `bzlmod` will lazily load dependencies.
4d42138
to
962eebd
Compare
@fmeum I thought you could commit to this repo :) Oops. Will add an owner as a reviewer! |
Apparently, I can't add reviewers now in the GH UI, but it looks like @Wyverald can merge changes. Pinging them in this comment :) |
Have you tried out the approach we discussed in #250 where the part using gazelle is separated out into its own module? I still think it's rather intrusive to have rules_go in basically everyone's dependency graph. |
As I understand it, For people not using |
I obviously don't like saying that, but unfortunately having a transitive Bzlmod dep on
We will try to stabilize this shortly after the Bazel 6 release, but I can't promise anything.
At least before both these issues have been fixed introducing a |
That's true, but as Fabian also pointed out, bringing in other modules sometimes does fetch them eagerly, particularly when toolchains are registered in them. Besides, adding dependencies has other costs -- version resolution takes more time and includes more noise, and a "vendor mode" setup ("download everything for me so that I can work offline") will fetch much more random stuff.
If by "repo" here you mean "git repo" instead of "Bazel repo", we need to normalize the expectation of multiple modules hosted in the same git repository. That would be the only sane way to avoid an explosion of the dependency graph. |
@Wyverald updated to be a two module, one git repo setup. |
The build is failing with
With |
@shs96c HEAD broke downstream projects, should be fixed in about an hour thanks to bazelbuild/bazel@7dcf0c3. |
… match the ones in gazelle
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.
nice start!
@@ -0,0 +1,24 @@ | |||
bazel_dep(name = "bazel_skylib", version = "1.3.0") |
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.
add a module(name="skylib_gazelle", version="...")
declaration here?
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.
Done.
MODULE.bazel
Outdated
@@ -14,8 +14,8 @@ bazel_dep(name = "platforms", version = "0.0.4") | |||
### INTERNAL ONLY - lines after this are not included in the release packaging. | |||
|
|||
# Gazelle extension is experimental | |||
bazel_dep(name = "rules_go", repo_name = "io_bazel_rules_go", version = "0.33.0") | |||
bazel_dep(name = "gazelle", repo_name = "bazel_gazelle", version = "0.26.0") | |||
bazel_dep(name = "rules_go", repo_name = "io_bazel_rules_go", version = "0.35.0") |
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.
is the plan to remove these?
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.
I can try removing them and see what breaks....
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.
Removed.
WORKSPACE
Outdated
@@ -69,17 +69,5 @@ register_unittest_toolchains() | |||
# github.com/bazelbuild/rules_go is available from io_bazel_rules_go and it | |||
# doesn't need to duplicatively fetch it. | |||
# gazelle:repository go_repository name=io_bazel_rules_go importpath=github.com/bazelbuild/rules_go |
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.
I'm not familiar with gazelle repository hints, do these need to be moved to gazelee/WORKSPACE?
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.
I've moved them, and everything still seems to build. Apparently, it's fine to move them.
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.
all looks good except for the question about the gazelle hints left over in the WORKSPACE file. thanks!
@shs96c Will we be adding instructions on how to load the |
Add the gazelle plugin to the distribution (bazelbuild#400)
After #400, the gazelle plugin has been cleanly separated out into its own bazel workspace, which will soon finally allow us to mark it stable. But this means: * we need to change our bazelci config to explicitly build and test it, since `bazel build //...` no longer includes the plugin; * we need to add proper distribution rules for it; * we need to update release instructions, since now we will have two distribution tarballs
To avoid everyone needing to take a dep on
rules_go
, we do the following:Regular Bazel users need to load
bazel_skylib_gazelle_plugin_workspace
and call that, and thenbazel_skylib_gazelle_plugin_setup
bzlmod
users need do nothing, but we now include therules_go
dep in theMODULE.bazel
shipped in the release. This is fine, becausebzlmod
will lazily load dependencies.