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

Release rules_kotlin as a Bazel module #660

Open
fmeum opened this issue Jan 15, 2022 · 9 comments
Open

Release rules_kotlin as a Bazel module #660

fmeum opened this issue Jan 15, 2022 · 9 comments

Comments

@fmeum
Copy link
Contributor

fmeum commented Jan 15, 2022

Bazel 5 will bring experimental support for a new system for external dependency management codenamed "bzlmod". Making rules_kotlin available within this system requires packaging it as a module and submitting it to the Bazel Central Registry.
Is this already being worked on? I would be willing to help, but do not understand the dependency structure well enough to take this on on my own.

@cgruber
Copy link
Collaborator

cgruber commented Feb 4, 2022

We are looking at it, but we have to look at how this affects those who aren't using 5, and aren't in the modules ecosystem. We're open to it, and ultimately will likely implement this, but if the migration path doesn't support some sort of way out for <5.0 bazel, we'll have to wait a release (of bazel) or two before we really get it done.

In the mean-time, we're looking into the mechanism and setting up a plan. I wouldn't count on this before 1.7 of the rules.

@comius
Copy link
Contributor

comius commented Dec 20, 2022

Main problems:

  • release tgz contains rkt_1_{4-7}.tgz, legacy.tgz which additionally describe Kotlin/Java compiler flags
  • compiler repository depends back on rules_kotlin, to export .jars with kt_jvm_import rules (circular deps are possible in bzlmod, however they are potentially problematic)

Goal: Make rules_kotlin work with and without bzlmod

I believe there should be just two repositories: rules_kotlin and kotlin_compiler. Bzlmod should handle kotlin_compiler as a dependency as naturally as possible. This then makes it easy for the users to select kotlin_compiler version and rules_kotlin version they want to use.

Proposal:

  1. Move kt_jvm_import (and kt_js_import) targets from the kotlin_complier repository into the rules_kotlin repository (just export files instead from kotlin_complier repo) to break dependency edge from compiler repo to rules_kotlin
  • alternative, bet that cyclic deps work and just depend on rules_kotlin (we'd need to release rules_kotlin and kotlin_compiler on bazel-central-registry at the same time)
  1. Release kotlin_compiler 1_4 to 1_7 on bazel-central-registry including the additional bzl files contained in rkt_1_{4,..7} , kt_{kotlinc,javac}_options rules and {kotlinc,javac}_options_to_flags.
    • or a more lightweight .bzl file, containing only a string list of available javac and kotlinc flags
  2. Make rules_kotlin/MODULE.bazel that has a dependency on kotlin_compiler (no repos for rkt_1_x)

There are other minor problems, which I'll attempt to solve separately.

WDYT?

@fmeum
Copy link
Contributor Author

fmeum commented Dec 20, 2022

Based on my own experience with the rules_go and gazelle Bazel modules that mutually depend on each other, I can say that this case does work but can also be painful to work with. I would suggest trying to break such cyclic dependencies before Bzlmod-ifying a repo.

comius added a commit to comius/rules_kotlin that referenced this issue Dec 22, 2022
Move Kotlin specific targets (like `kt_jvm_import`) from `BUILD.com_github_jetbrains_kotlin` to `//kotlin/compiler`.

This will make it possible to release `kotlin-compiler` module on `bazel-central-registry` without depending on `rules_kotlin`. The release will contain the new form `BUILD.com_github_jetbrains_kotlin` which doesn't depend on `rules_kotlin`.

RELNOTES[INC]: This breaks users that depend on `@com_github_jetbrains_kotlin//:*` targets. The same targets can be found under  `@io_bazel_rules_kotlin//kotlin/compiler:*`.

It's not possible to add an `alias` to `@com_github_jetbrains_kotlin` repository, becuase it would already create a dependency on `rules_kotlin` repository in the bzlmod world.

Technically it's possible to release 2 bzlmod modules that have a circular dependency. But this might create some unexpected problems. It addition it would be harder to convince `com_github_jetbrains_kotlin` owners to depend on `rules_kotlin`.

Works toward: bazelbuild#660
comius added a commit to comius/rules_kotlin that referenced this issue Dec 22, 2022
Add `capabilities.bzl` to Kotlin compiler repository. Generate `kt_kotlinc_options` rule from it, that is filter out options that are not available in a specific version.

This change makes a narrow interface between Kotlin compiler and Kotlin rules. It will make it possible to release and use new versions of Kotlin compiler independently from Kotlin rules.

The release of Kotlin compiler should include the new `capabilities.bzl` file.

The `capabilities.bzl` files were generated by grepping respective version of Kotlin compiler sources for `@Argument` annotation (some of them are not documented). The `legacy` file was generated from Kotlin compiler 1.3.0 additionally removing options that weren't available in `src/legacy`.

There are some minor differences from previous `src/legacy` - javac opts are the same for versions.

Works toward: bazelbuild#660
comius added a commit to comius/rules_kotlin that referenced this issue Dec 22, 2022
Remove `absolute_target` and use `Label` in the top-level bzl scope. This makes `Label` correctly evaluate to point to the repository where bzl file resides.

Bzlmod is more stringent about labels and `absolute_target` implementation doesn't work with it - the created labels are de-funct.

This works towards bazelbuild#660
It's one of the minor issues.
@comius comius mentioned this issue Dec 22, 2022
@comius
Copy link
Contributor

comius commented Dec 22, 2022

I prepared PRs that fix this issue:

First two PRs should be reviewed before Kotlin compiler is release on bazel-central-registry.

@restingbull
Copy link
Collaborator

restingbull commented Dec 22, 2022

  1. Move kt_jvm_import (and kt_js_import) targets from the kotlin_complier repository into the rules_kotlin repository (just export files instead from kotlin_complier repo) to break dependency edge from compiler repo to rules_kotlin

To keep the api stable (and avoid cyclical refs), we can use jvm_import. I've updated the pr.

release tgz contains rkt_1_{4-7}.tgz, legacy.tgz which additionally describe Kotlin/Java compiler flags

If I understand this correctly, the bzlmod does not allow for the practice of "sub repositories" -- instead, it provides extensions. If so, then it's just a matter of remapping the repos to extension and setting a default configuration.

Also, silly question: how do we register default toolchains?
Ah, interesting. You can do it in the MODULE.bazel. The docs do not make that clear.

comius added a commit to comius/rules_kotlin that referenced this issue Dec 23, 2022
Move Kotlin specific targets (like `kt_jvm_import`) from `BUILD.com_github_jetbrains_kotlin` to `//kotlin/compiler`.

This will make it possible to release `kotlin-compiler` module on `bazel-central-registry` without depending on `rules_kotlin`. The release will contain the new form `BUILD.com_github_jetbrains_kotlin` which doesn't depend on `rules_kotlin`.

RELNOTES[INC]: This breaks users that depend on `@com_github_jetbrains_kotlin//:*` targets. The same targets can be found under  `@io_bazel_rules_kotlin//kotlin/compiler:*`.

It's not possible to add an `alias` to `@com_github_jetbrains_kotlin` repository, becuase it would already create a dependency on `rules_kotlin` repository in the bzlmod world.

Technically it's possible to release 2 bzlmod modules that have a circular dependency. But this might create some unexpected problems. It addition it would be harder to convince `com_github_jetbrains_kotlin` owners to depend on `rules_kotlin`.

Works toward: bazelbuild#660
comius added a commit to comius/rules_kotlin that referenced this issue Dec 23, 2022
Add `capabilities.bzl` to Kotlin compiler repository. Generate `kt_kotlinc_options` rule from it, that is filter out options that are not available in a specific version.

This change makes a narrow interface between Kotlin compiler and Kotlin rules. It will make it possible to release and use new versions of Kotlin compiler independently from Kotlin rules.

The release of Kotlin compiler should include the new `capabilities.bzl` file.

The `capabilities.bzl` files were generated by grepping respective version of Kotlin compiler sources for `@Argument` annotation (some of them are not documented). The `legacy` file was generated from Kotlin compiler 1.3.0 additionally removing options that weren't available in `src/legacy`.

There are some minor differences from previous `src/legacy` - javac opts are the same for versions.

Works toward: bazelbuild#660
@yrom
Copy link

yrom commented Mar 24, 2023

How is it going? I tried to enable bzlmod, but rules_kotlin does not work properly and requires a large number of patches 😢 Then I gave up

@auzhva
Copy link

auzhva commented Jul 2, 2023

Hi! Are there any news from there? Thank you!

@restingbull restingbull assigned restingbull and unassigned comius Jul 7, 2023
@shs96c
Copy link
Contributor

shs96c commented Aug 30, 2023

Gentle nudge. Would love to be able to use rules_kotlin with bzlmod natively.

@luispadron
Copy link

+1 this is blocking some folks who depend on rules_kotlin from using bzlmod

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants