Skip to content

[Bzlmod][Twitter Scrooge] Creating a custom twitter_scrooge toolchain requires significant workarounds #1744

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

Open
FrankPortman opened this issue May 27, 2025 · 3 comments

Comments

@FrankPortman
Copy link
Contributor

FrankPortman commented May 27, 2025

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'

You can work around this via something like:

scala_deps = use_extension("//scala/extensions:deps.bzl", "scala_deps")
scala_deps.scala()
scala_deps.twitter_scrooge()

SCALA_VERSION="2.13.16"
version_suffix = "_%s" % SCALA_VERSION.replace(".", "_")
use_repo(
    scala_deps,
    "io_bazel_rules_scala_javax_annotation_api" + version_suffix,
    "io_bazel_rules_scala_mustache" + version_suffix,
    ... other non overrideable deps ...
)  

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.

@FrankPortman
Copy link
Contributor Author

@mbland
Copy link
Contributor

mbland commented May 27, 2025

@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?

@FrankPortman
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants