-
Notifications
You must be signed in to change notification settings - Fork 209
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
Comments
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. |
Main problems:
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:
There are other minor problems, which I'll attempt to solve separately. WDYT? |
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. |
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
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
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.
I prepared PRs that fix this issue:
First two PRs should be reviewed before Kotlin compiler is release on |
To keep the api stable (and avoid cyclical refs), we can use
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.
|
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
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
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 |
Hi! Are there any news from there? Thank you! |
Gentle nudge. Would love to be able to use |
+1 this is blocking some folks who depend on |
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.
The text was updated successfully, but these errors were encountered: