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

Allow default patches with go_deps #1984

Open
maffoo opened this issue Nov 22, 2024 · 2 comments · May be fixed by #1985
Open

Allow default patches with go_deps #1984

maffoo opened this issue Nov 22, 2024 · 2 comments · May be fixed by #1985

Comments

@maffoo
Copy link

maffoo commented Nov 22, 2024

The go_deps extension has a mechanism for having different default arguments for the underlying go_repository command. Currently there are overrides for build_directives, build_extra_args, and build_file_generation:

"DEFAULT_BUILD_EXTRA_ARGS_BY_PATH",
"DEFAULT_BUILD_FILE_GENERATION_BY_PATH",
"DEFAULT_DIRECTIVES_BY_PATH",

The code is written in a way that we one could specify new defaults, but this is currently not done: https://github.com/bazel-contrib/bazel-gazelle/blob/master/internal/bzlmod/go_deps.bzl#L156-L160

The go-tree-sitter library is used by the gazelle plugin for rules_python to parse python files during build file generation, and needs to be upgraded to a new version to support python 3.12 type parameter syntax (see bazelbuild/rules_python#2396). However, the new version of go-tree-sitter does not build with gazelle because it has uplevel references to c header files. We tried to fix this by applying patches in the rules python repo (see bazelbuild/rules_python#2413), but those overrides don't take effect when using using the rules python gazelle plugin because it is no longer the root module, so we would need the patches to be applied by bazel-gazelle.

@maffoo
Copy link
Author

maffoo commented Nov 22, 2024

Note that if gazelle could handle uplevel file references when generating build files then patches for go-tree-sitter would not be necessary, though it may still be desirable to have a mechanism for applying default patches.

@fmeum
Copy link
Member

fmeum commented Nov 22, 2024

I understand your use case, but maintaining patches to Go modules in this repo would certainly overstretch our responsibility and complexity budgets. For example, we would need to have a plan for when the patch needs to change as new versions of the module are released.

Have you considered making go-tree-sitter a BCR module instead? Gazelle has special support for BCR modules that are also Go modules and avoids duplicating them in the dependency graph. You can refer to the circl module for an example.

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

Successfully merging a pull request may close this issue.

2 participants