deps(gazelle): Bump rules_go from 0.41.0 to 0.55.0; gazelle from 0.31.0 (or 0.33.0 for bzlmod) to 0.40.0; go from 1.19.4 to 1.22.0#2962
Conversation
Bump `rules_go` from 0.41.0 to 0.55.0 Fixes bazel-contrib#2956. + Run `go get github.com/bazelbuild/[email protected]` for version bump. + Run `go mod tidy` to clean up stale deps + Run `bazel run //:gazelle_update_repos` + Figure out http_archive hashes and apply them for WORKSPACE users. + Also bump bazel-gazelle to address a warning: + `go get github.com/bazelbuild/[email protected]` + > Mismatch between versions requested for module > github.com/bazelbuild/bazel-gazelle > Bazel dependency version requested in MODULE.bazel: 0.40.0 > Go module version requested in go.mod: 0.31.1 > Please resolve this mismatch to prevent discrepancies between > native Go and Bazel builds + Update CHANGELOG.md accordingly
|
I'm not exactly sure how to fix the failing WORKSPACE tests. My assumption is that there's an issue with this go_repository being a nested module, and that go_repository(
name = "org_golang_x_tools_go_vcs",
importpath = "golang.org/x/tools/go/vcs",
sum = "h1:cOIJqWBl99H1dH5LWizPa+0ImeeJq3t3cJjaeOWUAL4=",
version = "v0.1.0-deprecated",
)Any thoughts? I thought that maybe some Thus far I'm unable to reproduce the issue locally, so fixing it might result in some CI spam... |
Reproduced via the very simple Investigating a fix. |
dougthor42
changed the title
|
@aignas I've solved the WORKSPACE stuff by bumping Example: Can you take a look? |
…ORKSPACE + 0.31, 0.32 errored out with the golang_x_tools//go/vcs issue from before + 0.33, 0.34, 0.35 have the wrong load sorting.
According to bazel-contrib/bazel-gazelle#1654 we need to call the gazelle_dependencies macro in WORKSPACE. We already do that in gazelle/WORKSPACE but it's not in the root WORKSPACE. Maybe we have to do it there, too...
|
Huzzah! I got the rest of the Gazelle stuff passing for WORKSPACE. Now I need to investigate the Windows builds and my tree-sitter fork... |
This reverts commit 2306ff4.
dougthor42
force-pushed
the
u/dthor/bump-rules_go-gh2956
branch
from
c91f3db to
6849424
Compare
|
TL;DR: Might need more updates to After much application of my head against a brick wall, I think I've come to the conclusion that bazel-contrib/rules_go#4298 did not fully resolve the "not importing C stuff" thing from bazel-contrib/bazel-gazelle#2059. As you can see from the commit history, I've tried jumping back to smacker/go-tree-sitter, which can't be done because it shares an issue with dougthor42/go-tree-sitter in that things fail on Windows (@shaldengeki saw this in #3060 too). I've also tried pulling in the official tree-sitter as @jbedard did in #2952. This attempt is why I think that rules_go is still broken, as we get: The source file is https://github.com/tree-sitter/tree-sitter-python/blob/master/bindings/go/binding.go and looks like: package tree_sitter_python
// #cgo CFLAGS: -std=c11 -fPIC
// #include "../../src/parser.c"
// #include "../../src/scanner.c"
import "C"
...Looking at the BUILD.bazel file that gazelle makes for that dependency, we see: And if we look at the project |
|
FWIW I've held back any more effort switching to https://github.com/tree-sitter/go-tree-sitter/ until I get some feedback on tree-sitter/go-tree-sitter#32 |
|
The summary thus far:
|
Finally remove the dougthor42/go-tree-sitter fork, fixing #2630. Admittedly we could have done this sooner had I figured things out sooner... but c'est la vie. Instead of using the BUILD.bazel files in dougthor42/go-tree-sitter, we basically vendor the build file via http_archive. This is different than using patches because non-root Bazel modules can still make use of the BUILD.bazel files we make. Background: The reason we migrated to dougthor42/go-tree-sitter in the first place was to support python 3.12 grammar. smacker/go-tree-sitter supported for python 3.12, but made a change to their file structure that Gazelle was unable to handle. Specifically, the python/binding.go file indirectly requires a c header file found in a parent directory, and Gazelle doesn't know how to handle that for `go_repository` (WORKSPACE) and `go_deps.from_file` (bzlmod). So dougthor42/go-tree-sitter created our own BUILD.bazel files that included the required filegroups and whatnot, thus negating the need for Gazelle to generate BUILD.bazel files. Future Work: This still doesn't resolve the issues with bumping rules_go and go seen in #2962, but it does simplify that investigation a bit as it's just one fewer thing to account for. It also doesn't address the desire to migrate to the official tree-sitter/go-tree-sitter repo, but @jbedard found some perf issues with that anyway (tree-sitter/go-tree-sitter#32).
|
Replaced by #3179. Good riddance to this PR, because it was super annoying for some reason. |
3 participants
Bump versions:
rules_gofrom 0.41.0 to 0.55.0gazellefrom 0.31.0 (or 0.33.0 for bzlmod) to 0.40.0gofrom 1.19.4 to 1.22.0Fixes #2956.
go get github.com/bazelbuild/[email protected]for version bump.go mod tidyto clean up stale depsbazel run //:gazelle_update_reposgo get github.com/bazelbuild/[email protected]