docs(bazel): stop pinning a Go patch version in the gazelle_python note - #213
Merged
Conversation
The TEND(tooling) comment named "our Go 1.26.4 SDK", which Renovate's 1.26.4 -> 1.26.5 bump (#210) left stale — it moved the go_sdk.download pins but not the prose. The patch version was never load-bearing: upstream bazel-contrib/rules_python#3416 frames the smacker/go-tree-sitter breakage as a cgo cross-compilation problem (Windows/Darwin), not a regression at some Go release, so the comment now refers to the pinned SDK without naming it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
MODULE.bazel'sTEND(tooling)note aboutrules_python_gazelle_pluginsaid the plugin's cgotree-sitter dependency "does not compile under our Go 1.26.4 SDK". Renovate's 1.26.4 → 1.26.5 bump
(#210) moved the three
go_sdk.download(version = …)pins but not the prose, so the comment named aversion the repo no longer uses. It now refers to "our pinned Go SDK".
Why no version at all
Checked upstream before genericizing, since a version-specific incompatibility would be worth
keeping: bazel-contrib/rules_python#3416
frames the
smacker/go-tree-sitterproblem as cgo making the gazelle binary hard to build/cross-compile(Windows
undefined: Node, Darwin targets), not as a regression at a particular Go release. Thepure-Go replacement, #3786, is still open,
so the rest of the note stands.
Other drift candidates
Swept the repo (
1\.26\.[0-9]across*.md,*.bazel,*.yml,*.py, plus a broadergo 1.xpass). Nothing else needs a fix:
docs/future-considerations.md:163— "the three real pins sat at1.26.4against ago.workalready on
1.26.5" is a past-tense account of the custom-manager incident. Genericizing it woulddestroy the point; historical records don't drift.
meta/scripts/test_check_go_work.py,test_check_modules.py,test__workspace.py—go 1.26.1in synthetic
go.work/go.modfixtures written to temp dirs. No assertion compares them to therepo's SDK, so they can't become false.
MODULE.bazel:45,50,55,.devcontainer/devcontainer.json:14,go.work:1,tools/network_infrastructure_maintenance/go.mod:3— real pins/directives, not prose.Validation
bazel mod graph --depth=1in the devcontainer — MODULE.bazel still resolves.pre-commit run --files MODULE.bazel— all hooks correctly skip (none targetsMODULE.bazel;their
files:filters arego.(mod|work|sum),*.py,*.go, etc.).go_sdk.downloadcustom manager pattern never matched this comment, soremoving the version doesn't touch pin coverage.
🤖 Generated with Claude Code