Implement a toolchain

[jadenPete]

This PR leverages the Bazel toolchain framework to replace configure_bootstrap_scala, configure_zinc_scala, and the scala attribute. Those rules were written before the framework existed, so it makes sense to replace it with a more modern, idiomatic alternative.

Note that this PR breaks existing repositories that use lucidsoftware/rules_scala, so it's necessary to migrate your repository before pulling in these changes. Here are the steps for doing so:

1. Remove the default_scala mapping in your WORKSPACE file
2. Replace calls to configure_bootstrap_scala, configure_zinc_scala with their register_*_toolchain equivalents
3. Update your call to scala_register_toolchains to provide a list of toolchains and a default toolchain
4. Profit

[jadenPete]

Rebased off of lucid-master.

[jadenPete]

Rebased off of lucid-master.

[jjudd]

Took a pass through and things mostly looked good to me. I had a few questions/comments.

[jjudd]

I imagine this string will never change, but it may be worth doing what the rules_go folks did and instead use a constant that we import. That way if this string ever needs to change, it will be easy to change.

https://github.com/bazel-contrib/rules_go/blob/a54de7c88bb3cb133f951f0e9817c09be42056cb/go/private/common.bzl#L16

Also, they use the fully qualified name, which is probably not a bad idea either. So @rules_scala_annex//rules/scala:toolchain_type

[jadenPete]

This sounds like a great idea, but if we ever need to move that constant, we'll need to update all the imports that reference it, which introduces the same problem.

Also, Is the fully-qualified name unnecessary? I prefer not to use those unless it's necessary. My understanding was that Bazel understood this was in rules_scala_annex, even if these rules are being used in another repository.

[jadenPete]

Oh, you meant defining that alias for internal use in this file. That makes a lot of sense; I'll do that.

[jjudd]

Do we want to be storing the original scala_toolchain_name like the rules_go folks did?

Because currently this will always reset to the original value, and I thought that you ran into a scenario where you could override things from the command line, which made that problematic.

I did this in the Play Routes and Twirl rules, in case it is at all helpful

    new_settings = {}
    new_settings[toolchain_setting_key] = attr.play_routes_toolchain_name

    # Store the original toolchain value, so we can reset it
    new_settings[original_toolchain_setting_key] = json.encode(settings[toolchain_setting_key])

    return new_settings

Then I reset it as follows:

    if settings[original_toolchain_setting_key] != "":
        new_settings = {}
        new_settings[toolchain_setting_key] = json.decode(settings[original_toolchain_setting_key])
        new_settings[original_toolchain_setting_key] = ""
        return new_settings
    else:
        return {}

[jadenPete]

Ah, I completely forgot about that. I'll go ahead and do that.

[jjudd]

Do we need the @@ for these or can we just use the single @?

[jadenPete]

You're right—it can. Do you know the difference between @//... and @@//...? I know the difference between @/foo//... and @@foo//..., but are @//... and @@//... the same?

[jjudd]

@@ is canonical name. Was introduced with bzlmod. AFAIK it's intended to be machine readable rather than human readable. https://bazel.build/rules/lib/builtins/Args.html

Label objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are //foo:bar, @repo//foo:bar and @@canonical_name+//foo:bar.bzl.

[jjudd]

Also https://bazel.build/concepts/labels

This link explains it better.

[jjudd]

One thing that's been bouncing around in my head and I don't know if I care about or not: we use scala_toolchain_name. I used a similar naming convention in the Play Routes and Twirl rules.

I wonder if some folks will think that means they're getting that particular label. When in reality they should get a toolchain with that name, which works with the right platform?

I don't think scala_toolchain_kind or scala_toolchain_type would necessarily be clearer. Curious your thoughts here.

[jadenPete]

Squashed.

[jadenPete]

Rebased off of lucid-master.

[jadenPete]

One thing that's been bouncing around in my head and I don't know if I care about or not: we use scala_toolchain_name. I used a similar naming convention in the Play Routes and Twirl rules.

I wonder if some folks will think that means they're getting that particular label. When in reality they should get a toolchain with that name, which works with the right platform?

I don't think scala_toolchain_kind or scala_toolchain_type would necessarily be clearer. Curious your thoughts here.

Yeah, I remember deliberating about the naming of scala_toolchain_name for some time. The attribute that's used in bazelbuild/rules_scala stores the desired Scala version, so I couldn't refer to that. I think "name" is clear enough, because if scala_toolchain_name stored the label of the desired toolchain, its name would be scala_toolchain_label, or just scala_toolchain.

[jadenPete]

Squashed.