Scala compiler plugin

[TomVasile]

trafficstars

This issue stems from a reddit question i posted: https://www.reddit.com/r/bazel/comments/anfk5t/bazel_and_scala_compiler_plugin_question/

To give some background:

Currently I use rules_scala in conjunction with sbt-bazel to try an convert from sbt to bazel. I'm currently hitting an issue with the 'kind-projector' plugin not being used during the build. ie. compilerPlugin("org.spire-math" % "kind-projector" % "0.9.8")

I'm wondering how does one include such plugins?

[ittaiz]

Hi, I see in the linked reddit question that @johnynek gave you a solution on a per target basis. Did you try it?

[BardurArantsson]

(I'm a noob at Bazel, so please correct me if I'm totally off on how one is "supposed" to achieve what I'm trying to do...)

Is anybody who's working on rules_scala able to provide guidance on how to implement some more convenient mechanism for "scoped" specification of the compiler plugins? As an example I'd like to be able to have a foo/bar/BUILD file say something like "all scala_library calls anywhere under /foo/bar will have compiler plugins A, B, C... unless otherwise specified".

(The example project linked in the Reddit comments has atrophied a bit -- meaning the approach is probably a bit brittle, and also seems a little bit hackish... it would be really nice if we could get 'native' support for specifying the default plugins for the scala toolchain in a "scoped" way.)

[ittaiz]

Just to make sure we’re aligned- You know that you can define compiler plugin for all the repo using a toolchain, right? (As well as obviously per specific targets). If you know this and still want the “scoping” I’d love to learn a bit more about your use case. Your request as is isn’t easy to implement.

On Sat, 16 Nov 2019 at 9:39 Bardur Arantsson [email protected] wrote:

(I'm a noob at Bazel, so please correct me if I'm totally off on how one is "supposed" to achieve what I'm trying to do...)

Is anybody who's working on rules_scala able to provide guidance on how to implement some more convenient mechanism for "scoped" specification of the compiler plugins? As an example I'd like to be able to have a foo/bar/BUILD file say something like "all scala_library calls anywhere under /foo/bar will have compiler plugins A, B, C... unless otherwise specified".

(The example project linked in the Reddit comments has atrophied a bit -- meaning the approach is probably a bit brittle, and also seems a little bit hackish... it would be really nice if we could get 'native' support for specifying the default plugins for the scala toolchain in a "scoped" way.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/rules_scala/issues/684?email_source=notifications&email_token=AAKQQF5QC6NHIKDOHMTTXJTQT6PTBA5CNFSM4GUV57LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHLXLA#issuecomment-554613676, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQQF6DXTIQULGF2DA2OZTQT6PTBANCNFSM4GUV57LA .

[BardurArantsson]

Are there any examples of that your suggestion?

I've been trying the suggestion from the Reddit thread, specifically this type of approach: https://github.com/johnynek/bosatsu/blob/master/tools/scala.bzl and then just using instead of the "standard" scala_rules. (The linked file is a bit out of date, but nothing major.)

My use case is perhaps a bit wonky... We cannot have all of our code in a single monorepo, so what I'd like to do is have several of our (usually independent, but sometimes interdependent) libraries in a single repo -- the catch being that we might want different sets of compiler plugins (scala options, etc.) for each of the libraries. I could "solve" this by just having a single BUILD in the source root of each of the libraries and globbing **/*.scala, but that seems to kind of go against the idea of fine-grained dependencies which Bazel encourages.)

[ittaiz]

Indeed recursive globs (**) are very counterproductive. I’ll try to give examples once I have a bit more info.

These libraries- are they consumed in other repos via bazel? The idea of bazel is source dependencies which means that other repos take your sources and build them in their context (for example with their toolchains).

If you’re only talking about your own repo then I’d add one more question- is having all compiler plugins available for all targets an option?

On Sat, 16 Nov 2019 at 13:36 Bardur Arantsson [email protected] wrote:

Are there any examples of that your suggestion?

I've been trying the suggestion from the Reddit thread, specifically this type of approach: https://github.com/johnynek/bosatsu/blob/master/tools/scala.bzl and then just using instead of the "standard" scala_rules. (The linked file is a bit out of date, but nothing major.)

My use case is perhaps a bit wonky... We cannot have all of our code in a single monorepo, so what I'd like to do is have several of our (usually independent, but sometimes interdependent) libraries in a single repo -- the catch being that we might want different sets of compiler plugins (scala options, etc.) for each of the libraries. I could "solve" this by just having a single BUILD in the source root of each of the libraries and globbing **/*.scala, but that seems to kind of go against the idea of fine-grained dependencies which Bazel encourages.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/rules_scala/issues/684?email_source=notifications&email_token=AAKQQF3MZ437CX6Y2PIT673QT7LM7A5CNFSM4GUV57LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHPPYQ#issuecomment-554629090, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQQF7MOPFSXFR7GLMXGLDQT7LM7ANCNFSM4GUV57LA .

[ittaiz]

@BardurArantsson should this be closed?

[BardurArantsson]

Yes, sorry, meant to get back to you.

After having played with it a bit more, it does make sense that my suggestion for "un-boilerplating" the build is probably not a Bazel-like thing (and I can see why it would be difficult within the model. So thanks for that insight!)

I have no objections to closing, but that said, it wasn't actually me who opened the issue, but @TomVasile .

[ittaiz]

right, @TomVasile same question :)

[lexspoon]

Before closing the ticket, I have a few small requests just to clean up the current state of things, not to make any major new improvement.

Primarily, can the current best approach be documented, both how to enable a plugin on a single scala_library, and also how to enable it globally for a Scala toolchain?

For the case of updating a single scala_library, here is what I eventually discovered is functional:

scala_library(
    name = "data-bound",
    srcs = glob(["src/main/scala/**/*.scala"]),
    plugins = ["@maven//:org_scalamacros_paradise_2_12_19"],
    ...
)

This seems very nice to use but just hard to discover, right now. In particular, the documentation page for scala_library doesn't mention the plugins attribute.

For adding a plugin to an entire Scala toolchain, I simply could not figure it out. There is no plugins attribute on setup_scala_toolchain. I tried specifying a -Xplugin: option to scalac_opts, like this:

    scalacopts = [
        "-Xplugin:$(execpath @maven//:org_scalamacros_paradise_2_12_19)",
    ],

However, this didn't work due to my execpath argument not being in the deps of some rule that ends up using this string. I tried adding it to the various classpath and deps attributes of setup_scala_toolchain, but I couldn't find a way that works.

Perhaps most simply, could a plugins option be added to setup_scala_toolchain? If that is not feasible, then could some method of enabling a plugin be documented?