dragonsinth commented 2 years ago

For people who are extending gazelle with other languages, IDE development is a chore. There's no easy way to produce a working gazelle binary with a desired set of languages configured.

Proposal:

1) Move almost all of //cmd/gazelle into a sub-package, leaving only main() and languages. 2) Have the sub-package expose a single Run() entry point.

Reasoning:

Developers extending gazelle could then trivially create their own custom gazelle binary, depending on the gazelle packages, with customized languages and minimal fuss. Having a custom gazelle binary that doesn't require bazel-driven code generation means developers can easily build and debug in an IDE.

sluongng commented 2 years ago

I have yet to understand the motivation here. What is the pain point that you are trying to solve?

Having a custom gazelle binary that doesn't require bazel-driven code generation means developers can easily build and debug in an IDE.

It's not very clear to me what use case do you have in mind that is not possible with current setup.

Having a custom gazelle binary that doesn't require bazel-driven code generation

Keep in mind that this repository, similar with rules_go, is built by and made for Bazel. This means that we would not be able to guarentee backward compatible for non-Bazel use case. Although if it's possible and easy to do, then I am all for it 👍 . rules_go itself has many packages that does not work with go build and/or go mod by default.

dragonsinth commented 2 years ago

I have yet to understand the motivation here. What is the pain point that you are trying to solve?

I want to be able to easily debug and iterate on plugin/language development from an IDE.

Having a custom gazelle binary that doesn't require bazel-driven code generation means developers can easily build and debug in an IDE.

It's not very clear to me what use case do you have in mind that is not possible with current setup.

I want to be able to write a simple gazelle binary like this:

gazelle_impl.Run(languages, wd, os.Args[1:])

Where languages includes the custom language I'm working on and lives in my own repo, without forking the entirety of cmd/gazelle, which is a big package.

The normal way of building gazelle with custom languages goes entirely through bazel and is not IDE friendly.

Keep in mind that this repository, similar with rules_go, is built by and made for Bazel. This means that we would not be able to guarentee backward compatible for non-Bazel use case. Although if it's possible and easy to do, then I am all for it 👍 . rules_go itself has many packages that does not work with go build and/or go mod by default.

Gazelle is completely compatible with the normal Go build. If that were not true, you couldn't go get github.com/bazelbuild/bazel-gazelle and have it work correctly.

sluongng commented 2 years ago

Ok thats a lot clearer to me.

Let me attempt to rephrase the ask here and please correct me if I am wrong

Background

In Bazel workspace which does use Go, but would still want to leverage Gazelle and custom language extension(s) to generate BUILD files, there is a need to pre-build the custom Gazelle binar(ies) without using Bazel and vendor the binar(ies) into workspace.

Furthermore, it's also difficult to troubleshoot / debug the custom language extensions due to Bazel-based code generation approach.

Proposal

Provide runner package (actual name TBD) where most of the execution logic is moved from //cmd/gazelle over. runner would export Run() interface for other packages to consume.
//cmd/gazelle package would retains main() and languages and call into runner.Run() with the appropriate parameters.
Non-bazel projects could consume https://github.com/bazelbuild/bazel-gazelle/runner via go module and provide their own language extensions through Run()

Overall I think this is a reasonable request to implement 👍

Definitely can see a lot of folks who are running Java-only or NodeJS-only workspace who could be benefit from this.

sluongng commented 2 years ago

statically linkable

This in the title made me think of something else entirely. I.e. having to statically link gazelle binary against cgo and custom sysroot... Which makes very little sense in this context 🤔

But who know... may be you have a Gazelle extension doing just that 😆

dragonsinth commented 2 years ago

@sluongng yes, that's exactly it. Thank you for helping me describe this better! I changed the title of the issue, is that better?

dragonsinth commented 2 years ago

1292 is the proof of concept I built, but can definitely iterate on it. I could go and update it to use `bazel-gazelle/runner` if you think that's a good place to put it.

bazel-contrib / bazel-gazelle

allow building gazelle cmd using Go with custom plugins, to ease development #1291

Background

Proposal

1292 is the proof of concept I built, but can definitely iterate on it. I could go and update it to use `bazel-gazelle/runner` if you think that's a good place to put it.

bazel-contrib / bazel-gazelle

allow building gazelle cmd using Go with custom plugins, to ease development #1291

Background

Proposal

1292 is the proof of concept I built, but can definitely iterate on it. I could go and update it to use bazel-gazelle/runner if you think that's a good place to put it.

1292 is the proof of concept I built, but can definitely iterate on it. I could go and update it to use `bazel-gazelle/runner` if you think that's a good place to put it.