Insulate toolchain options from breaking rules_scala bootstrap code

[andyscott]

Downstream workspaces using a custom Scala toolchain can't use the scala_test rule with certain Scala compiler flags enabled.

It seems custom Scala toolchains will be used to compile the bootstrapping Scala code in rules_scala for running scala tests. In particular, flags to enable fatal warnings and warnings on unused imports cause scala_test to be unusable.

A short term fix is to clean up these bootstrapping files so that they work under strict Scala compiler flags. I took a look at a more thorough solution but I couldn't come up with anything quickly.

[ittaiz]

I’m not sure what you’re looking (toolchain isolation) for is an option in Bazel due to source dependency. How about opening an issue with bazel asking if it’s a relevant request? Another option would be to build rules Scala with the strictest modes as to support all users

…

On Thu, 1 Mar 2018 at 22:49 andy g scott ☜ ***@***.***> wrote: Downstream workspaces using a custom Scala toolchain can't use the scala_test rule with certain enable Scala compiler flags enabled. It seems custom Scala toolchains will be used to compile the bootstrapping Scala code in rules_scala for running scala tests. In particular, flags to enable fatal warnings and warnings on unused imports cause scala_test to be unusable. A short term fix is to clean up these bootstrapping files so that they work under strict Scala compiler flags. I took a look at a more thorough solution but I couldn't come up with anything quickly. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#432>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF4q_s2SYBT_6DilClFHxEmiEInd4ks5taF7igaJpZM4SY-FR> .

[johnynek]

+1 for more strictness by default.

[andyscott]

@ittaiz I've adjusted the title a bit to hopefully be less misleading.

AFAIK in my recent adventures with Bazel, toolchains operate globally. Seems we need a way to insulate toolchain options for Scala from breaking the use of rules_scala in a workspace.

[ittaiz]

I agree, that’s why I said it’s a bazel side issue if you want to change it. Do you have any suggestions on how to insulate it other than building rules_scala with the strictest defaults?

…

On Fri, 2 Mar 2018 at 1:25 andy g scott ☜ ***@***.***> wrote: @ittaiz <https://github.com/ittaiz> I've adjusted the title a bit to maybe be a bit less misleading. AFAIK toolchains operate globally. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#432 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIFxyiimgsST5PI4o5lK8ny8ynoJc1ks5taINsgaJpZM4SY-FR> .

[ittaiz]

@andyscott I think we should either close this issue in favor of a bazel one or rename it to clarify this issue is solely about making rules_scala work with wfatal and the rest. WDYT?

[andyscott]

We could perhaps close this in favor of a more general toolchain issue.

Toolchains strike me as the standard way to get tools off the host environment. For Scala, this isn't needed, so I'd like to discuss the removal of toolchains for boostrapping Scala compilation.

[ittaiz]

More general in what sense?
Getting tools off of the host environment is one use case but toolchains in general belong to the world of configurability.
Configuring then scala SDK as well as the scalacopts are classic toolchain use cases.

Why should we remove toolchains from our scala code?

[dsilvasc]

You might be able to isolate settings for rules_scala with platform constraints: you could define a platform @rules_scala//:bootstrap-platform and set restricted_to to that platform in the targets defined in the rules_scala repo.

The consumers could have one scala toolchain for their application code (maybe stricter, maybe plus-one deps) and another scala toolchain to compile rules_scala (with whichever settings rules_scala requires).

[ittaiz]

interesting, doesn't that require support for using multi platform in a single invocation in bazel?
Bazel is very oriented towards everything being one mono repo together, the above scenario doesn't sound like it will work to be honest