FR: Gazelle Kotlin Support

[rob-pomelo]

Hi is there any thought / interest in adding kotlin support to the gazelle extension?

Have briefly started to look at the changes required and curious if its on others radar.

Thanks!

[illicitonion]

Would gladly review some PRs (with tests) to enable this!

[MorganR]

I've put up a (very messy, don't use it) PR up (#313 ) for discussion on this

[shs96c]

Thank you for the PR. I'm pinging @restingbull, as he might be interested in this being part of rules_kotlin. We can work together to find the best place for this :)

[MorganR]

I'd also be curious what @alexeagle thinks about merging Kotlin support in with the Java plugin, given his experience from the independent Kotlin plugin.

[restingbull]

Hm. We are generally trying to keep our maintenance footprint small, and adding Go to the dependencies is a bit non-ideal for us.

@Bencodes @nkoroste -- Thoughts?

[MorganR]

@shs96c, I understand why it seems like rules_kotlin would be a good spot for this, but I actually think that if someone is using Kotlin specifically with the JVM, then the best place for handling those rules is in the same plugin that handles the Java rules. I put more thoughts about why this is the case in the draft PR I linked above.

The only new dependency it adds to rules_jvm is one new Maven dependency on the "kotlin" package for parsing the Kotlin files.

[shs96c]

I am quite persuaded by the argument that kotlin and java source is often co-mingled in a way that other JVM-based languages don't seem to do.

[alexeagle]

FWIW We already have a Kotlin gazelle extension over here: https://github.com/aspect-build/aspect-cli/tree/main/gazelle/kotlin written by @jbedard

There are no great options for where to place Gazelle extensions since they're always compiled from source and introduce new toolchain dependencies (e.g. you'd want to use Tree-Sitter and that needs a C++ toolchain) IMO bazel-contrib/bazel-gazelle#938 is needed, so that Gazelle binary can load extensions that rulesets ship as pre-built binaries on their releases page.

[MorganR]

I'm aware of the existing extension, but had trouble using it in a repo with mixed Kotlin and Java.

@alexeagle or @jbedard, do either of you think there is merit to merging the two? I discussed this a bit in the related issue, but would especially like your insights having worked on the Kotlin plugin.

[MorganR]

Also I agree with you Alex that having Gazelle interact with subprocesses directly would be a nice improvement, though it doesn't seem required. The Java extension currently gets around this by starting its own Java-based gRPC server for parsing.

However, that makes me wonder if you could extend that idea further to something akin to an LSP or BSP, but for Gazelle? For larger codebases, it might be helpful to have a long-running process that can handle incremental changes, rather than processing everything from scratch on each invocation. I'm not sure if Gazelle already does some kind of local file caching or other technique to improve this.

[alexeagle]

There's some effort going on in the Gazelle repo to reduce the amount of tree-walking it does, to make it faster to re-run.

The Java plugin having a gRPC server is actually a real pain for the amount of dependencies it has. #318

[reddaly]

My org sponsored the Kotlin plugin development, and I have some pending contributions to it that I'd like to get submitted once we resolve where the code will live.

My experience with bzlmod so far makes me appreciate having fine-grained bzlmod modules. I want to understand how the bzlmod packaging of this will work if embedded in rules_jvm. It could be messy if the extension (1) requires certain versions of rules_jvm or rules_kotlin, (2) is released using the rules_jvm or rules_kotlin release process, and (3) shares the same bzlmod module as rules_jvm or rules_kotlin.

From a version management and release perspective, it seems simplest to me to spawn a new repo for the gazelle plugin with its own release process and bzlmod module. There is a risk that the new repo will not stay up to date with changes in rules_jvm and rules_kotlin. Another potential downside is a gazelle extension in a separate repo might not benefit from the same level of visibility and maintenance benefits compared to the extension living in rules_jvm. I think the simplicity of a separate repo with only gazelle extension concerns outweighs the potential downsides, but I'm curious to hear other opinions from more successful open-source repo maintainers.

[alexeagle]

My primary concern is with abandonware in the Bazel ecosystem. A new repo does give someone the freedom to have their own release cadence, but I don't know who the someone would be or where the repo would live. Would you want to put it with your repos in https://github.com/gonzojive?tab=repositories ?

It also makes versioning more complicated, because such an independent module would have to express constraints such as "which versions of rules_kotlin does version X support". If rules_kotlin 1.2.3 includes both rules and generators for those rules, it's much easier for users to reason about a single upgrade.