doc: link to @bazel_skylib//gazelle/bzl [skip ci]

[jayconrod]

• Link to @bazel_skylib//gazelle/bzl extension.
• Remove link to rules_sass extension, since the PR was closed.

[jayconrod]

TODO

• Wait for Move Gazelle extension to //gazelle/bzl and change package name bazel-skylib#261 to be merged.
• Update example to refer to that extension, since it's a good external example.

cc @achew22

[achew22]

Would you be okay including it as a default plugin?

[jayconrod]

Would you be okay including it as a default plugin?

Not yet... but I think we should eventually.

My main worry is that if something is included in the default Gazelle binary, then I'll be responsible for supporting and maintaining it. I'm stretched pretty thin right now (rules_go and Gazelle are not my main projects), and I can't take that on. bzl_library probably wouldn't be too much work, but someone could eventually make the same request for something like rules_cc or rules_haskell. For that reason, I've encouraged folks to develop extensions outside the Gazelle repo.

That approach hasn't worked well. I know there are a lot of private extensions for specific use cases, which is great, but there aren't any public extensions for major languages. That's probably for the same reason: rule owners don't want to develop, support, or maintain the extensions. And that's understandable: if you own rules_rust, you don't want to learn Go to do this. Even if ownership is delegated to the folks who write the extensions, those people may not have write access or control over the release schedule of the containing repository (as we are discovering).

Architecturally, in order for Gazelle to be more useful, it may be better for extensions to be developed here, but people adding extensions will need to take ownership and will need to respond to issues, fix bugs, and so on.

I think that's basically the right move, but needs more thought for now.

[achew22]

My main worry is that if something is included in the default Gazelle binary, then I'll be responsible for supporting and maintaining it. I'm stretched pretty thin right now (rules_go and Gazelle are not my main projects), and I can't take that on. bzl_library probably wouldn't be too much work, but someone could eventually make the same request for something like rules_cc or rules_haskell. For that reason, I've encouraged folks to develop extensions outside the Gazelle repo.

This is extremely reasonable to me. The primary thing that jumps to mind for me would be, should rules_go house the go plugin to gazelle? If I prepared a CL that grafted the history of the parts of the Gazelle repo that logically are a part of rules_go into the rules_go repo it would enhance the understanding that rules_x should house its gazelle plugin, like starlark does.

if you own rules_rust, you don't want to learn Go to do this

Out of curiosity, what would you think about having some kind of plugin system to Gazelle where you could communicate bidirectionally with a binary over stdin/out in a quasi gRPC kind of fashion? This would allow people to write in a language they're more comfortable in, maybe even import the AST engine from the compiler they're targeting.

[jayconrod]

The primary thing that jumps to mind for me would be, should rules_go house the go plugin to gazelle?

Funny you should mention that... Originally, Gazelle, fetch_repo, and go_repository were part of rules_go. I moved them into a new repository so that rules_go could be used without pulling Gazelle's dependencies and so that the two project didn't have to be released together. At the time, Gazelle didn't have an extension mechanism, so Go and proto support came over together.

I think those reasons are still valid, and it's another argument against putting extensions in rule repositories. The dependency thing isn't necessarily a definitive argument though: go_rules_dependencies and gazelle_dependencies could still be separate macros if they were in the same repo.

Out of curiosity, what would you think about having some kind of plugin system to Gazelle where you could communicate bidirectionally with a binary over stdin/out in a quasi gRPC kind of fashion? This would allow people to write in a language they're more comfortable in, maybe even import the AST engine from the compiler they're targeting.

Could work. There could be a generic stub extension library that implements that. You'd still have to write a little Go code to provide a NewLanguage function to set that up. Maybe gazelle_binary could even generate that for you depending on what kind of target it's given.

[sluongng]

Oh it took me wayyy to long to find this PR hanging.

@jayconrod @achew22 is there any pending items here that I could help out to get this merged? It's a very trivial doc change that let people know about the existing extension for Starlark

[achew22]

If you want to merge this I'm definitely okay with that