Compatibility with rules_nixpkgs for toolchains.

[DiCaius]

I use https://github.com/tweag/rules_nixpkgs to manage my toolchains and some other deps, I was trying to figure out how to get it to work with rules_kotlin but I suspect this is not possible due to the way toolchains work.

I currently have this in my WORKSPACE:

RULES_NIXPKGS_SHA = "33fd540d0283cf9956d0a5a640acb1430c81539a84069114beaf9640c96d221a"

RULES_NIXPKGS_VERSION = "81f61c4b5afcf50665b7073f7fce4c1755b4b9a3"

http_archive(
    name = "io_tweag_rules_nixpkgs",
    sha256 = RULES_NIXPKGS_SHA,
    strip_prefix = "rules_nixpkgs-%s" % RULES_NIXPKGS_VERSION,
    urls = ["https://github.com/tweag/rules_nixpkgs/archive/%s.tar.gz" % RULES_NIXPKGS_VERSION],
)

load("@io_tweag_rules_nixpkgs//nixpkgs:repositories.bzl", "rules_nixpkgs_dependencies")

rules_nixpkgs_dependencies()

load("@io_tweag_rules_nixpkgs//nixpkgs:nixpkgs.bzl", "nixpkgs_git_repository", "nixpkgs_package")

nixpkgs_git_repository(
    name = "nixpkgs",
    revision = NIXPKGS_REVISION,
    sha256 = NIXPKGS_SHA,
)

nixpkgs_package(
  name = "kotlin",
  attribute_path = "kotlin",
  repositories = { "nixpkgs": "@nixpkgs//:default.nix" },
)

This provides me filegroups with binaries and internal libraries, but I suspect there's no way to get from these filegroups to something that I can pass to define_kt_toolchains. Is that the case?

[phildawson-ct]

I've had a look at this too. It doesn't look posible as things stand. As best I can tell, allowing user defined filegroups to be used in toolchain definitions would require a significant rework of how rules_kotlin handles toolchains.

Currently the toolchain definition is hard-coded to grab an upstream compiler release archive from jetbrains and inject [BUILD](https://github.com/bazelbuild/rules_kotlin/blob/master/src/main/starlark/core/repositories BUILD.com_github_jetbrains_kotlin.bazel) files to provide targets for the required libraries and executables with quite a lot of hard-coded paths.

I'm also not sure how user-defined filegroups containing compilers would work with the current versioning scheme for compiler options and such.

cc @ulfjack @Yannic

[cgruber]

Yeah, this one is new to us. We can look at it, but it's not (yet) a high-priority. It seems to be pulling lots of different things from git repositories, and we carefully manage what versions of kotlinc are pulled for which builder, etc. So it seems non-trivial. We're taking a cursory look.