You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From what I understand, there are 2 (independent? complementary?) paths to create a custom twitter_scrooge toolchain.
You can either invoke setup_scrooge_toolchain or use the tag class a la scala_deps.twitter_scrooge(libthrift = ..., ....).
In the former case, supplying an override to every param in the constructor leads to this error, due to implicit non overrideable labels being summoned deeper in the macro:
no such package '@@[unknown repo 'io_bazel_rules_scala_scopt_2_13_16' requested from @@]//': The repository '@@[unknown repo 'io_bazel_rules_scala_scopt_2_13_16' requested from @@]' could not be resolved: No repository visible as '@io_bazel_rules_scala_scopt_2_13_16' from main repository and referenced by '//tools/scala:compiler_classpath_provider'
but this is not obvious, and requires you to invoke scala_deps.scala() even if you had successfully obviated that call previously via a custom Scala toolchain.
In the latter case (using the tag class and providing overrides), we hit a label vs string issue:
@@rules_scala+//scala/extensions:rules_scala++scala_deps+rules_scala_toolchains: expected value of type 'string' for dict value element, but got Label("@@rules_jvm_external++maven+maven//:org_apache_thrift_libthrift") (Label)
ERROR: /private/var/tmp/_bazel_fp/2927ef64b11207240f16497f643a99d5/external/rules_scala+/scala/toolchains.bzl:228:26: Traceback (most recent call last):
File "/private/var/tmp/_bazel_fp/2927ef64b11207240f16497f643a99d5/external/rules_scala+/scala/extensions/deps.bzl", line 227, column 21, in _scala_deps_impl
scala_toolchains(
File "/private/var/tmp/_bazel_fp/2927ef64b11207240f16497f643a99d5/external/rules_scala+/scala/toolchains.bzl", line 228, column 26, in scala_toolchains
scala_toolchains_repo(
Error in repository_rule: failed to instantiate 'scala_toolchains_repo' from this module extension
In an ideal world, the preferred route of creating a custom twitter_scrooge toolchain - or pros/cons of either route - is well documented, and all overrides are self contained in one call.
The text was updated successfully, but these errors were encountered:
@simuons Feel free to assign this one to me, too. Looks like we need to make all the setup_scrooge_toolchain deps overridable (and add those fields to scala_deps.twitter_scrooge(), too.)
Plus, I need to restore a Label in setup_scrooge_toolchain, too (after adding Label instances to fix setup_scala_toolchains and scala_cross_version_select in #1742).
As a side note, I think we could release 7.0.1 once #1745 lands. Then I can hopefully get to this issue and #1743 this week, and we can release 7.02. Or, if you prefer, you can wait for me to get to this and #1743 first, and then release 7.0.1. What do you think?
Friendly bump here - I am happy (and think I see a path) to patch this for my company with something that gets the job done but is probably not what you'd want landing in rules_scala. So I just wanted to check in quickly to see if anybody was working on a more robust solution.
Uh oh!
There was an error while loading. Please reload this page.
From what I understand, there are 2 (independent? complementary?) paths to create a custom
twitter_scrooge
toolchain.You can either invoke
setup_scrooge_toolchain
or use the tag class a lascala_deps.twitter_scrooge(libthrift = ..., ....)
.In the former case, supplying an override to every param in the constructor leads to this error, due to implicit non overrideable labels being summoned deeper in the macro:
You can work around this via something like:
but this is not obvious, and requires you to invoke
scala_deps.scala()
even if you had successfully obviated that call previously via a custom Scala toolchain.In the latter case (using the tag class and providing overrides), we hit a label vs string issue:
In an ideal world, the preferred route of creating a custom
twitter_scrooge
toolchain - or pros/cons of either route - is well documented, and all overrides are self contained in one call.The text was updated successfully, but these errors were encountered: