Remove @io_bazel_rules_scala or replace with Label #1696
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Removes all remaining internal usages of `@io_bazel_rules_scala` without changing any actual logic. Part of bazel-contrib#1482 and bazel-contrib#1652, this is the last change required before adding Bzlmod compatibility. Updates `WORKSPACE` files to use `@rules_scala` and `scala_register_toolchains()` instead of `@io_bazel_rules_scala` and `register_toolchains("@io_bazel_rules_scala_toolchains//...:all")`. Also adds all the scripts run in CI to `test_all.sh`, plus `dt_patches/dt_patch_test.sh`. Leaves `@io_bazel_rules_scala_config` as is for now, because it's a documented public interface. It can be easily changed and documented in a future commit if desired. Also doesn't change the `io_bazel_rules_scala_` prefix for Maven artifact repos. This could also be done and documented in a future commit if desired. --- This change enables `WORKSPACE` and Bzlmod users to import `rules_scala` as `rules_scala`, instead of requiring `io_bazel_rules_scala` due to internal dependencies. i.e., `WORKSPACE` users can still use `http_archive` to import `rules_scala` as `io_bazel_rules_scala`. Bzlmod users will be able to call `bazel_dep(name = "rules_scala", repo_name = "io_bazel_rules_scala")`. However, `io_bazel_rules_scala` is no longer required by `rules_scala` itself.
simuons
approved these changes
Feb 14, 2025
This was referenced Feb 20, 2025
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Feb 26, 2025
Shortens `@io_bazel_rules_scala_config` to `@rules_scala_config` in light of the `@io_bazel_rules_scala` removal in bazel-contrib#1696. Part of bazel-contrib#1482. Adds a section to `README.md` indicating this as a breaking change, with advice on working around any breakages that aren't immediately fixable. Per @simuons's advice in bazel-contrib#1703 (comment).
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Feb 28, 2025
Shortens `@io_bazel_rules_scala_config` to `@rules_scala_config` in light of the `@io_bazel_rules_scala` removal in bazel-contrib#1696. Part of bazel-contrib#1482. Adds a section to `README.md` indicating this as a breaking change, with advice on working around any breakages that aren't immediately fixable. Includes updates the "Builtin repositories no longer visible by default under Bzlmod" section to improve clarity. Per @simuons's advice in bazel-contrib#1703 (comment).
simuons
pushed a commit
that referenced
this pull request
Feb 28, 2025
Shortens `@io_bazel_rules_scala_config` to `@rules_scala_config` in light of the `@io_bazel_rules_scala` removal in #1696. Part of #1482. Adds a section to `README.md` indicating this as a breaking change, with advice on working around any breakages that aren't immediately fixable. Includes updates the "Builtin repositories no longer visible by default under Bzlmod" section to improve clarity. Per @simuons's advice in #1703 (comment).
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 15, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are only necessary for target string literals within `BUILD` macros and `BUILD` or `.bzl` files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 15, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 15, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 21, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 21, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 21, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 27, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 27, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 27, 2025
Removes all the `Label` wrappers added in bazel-contrib#1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind bazel-contrib#1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
simuons
pushed a commit
that referenced
this pull request
Apr 28, 2025
Removes all the `Label` wrappers added in #1696 that aren't strictly necessary. Removed instances: ```sh $ git show -p | grep '^- .*Label(' | wc -l 88 ``` Remaining instances: ```sh $ git ls-files | xargs grep '[^A-Za-z0-9]Label(' | wc -l 31 ``` Inspired by research I did while writing a blog post reflecting upon the motivations behind #1696. Bazel evaluates target string literals in the context of the repository that appears to contain the assignment of the literal to a `Label` attribute. `Label` wrappers are necessary for target string literals within macros, passed to external functions, and included in files generated by a repository rule. This ensures that the targets refer to the originating repository by preventing Bazel from interpreting them within the context of the repository using them. Keeping the `Label` wrappers doesn't hurt, but leaving only the ones that are required helps those instances stand out.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Removes all remaining internal usages of
@io_bazel_rules_scalawithout changing any actual logic. Part of #1482 and #1652, this is the last change required before adding Bzlmod compatibility.Updates
WORKSPACEfiles to use@rules_scalaandscala_register_toolchains()instead of@io_bazel_rules_scalaandregister_toolchains("@io_bazel_rules_scala_toolchains//...:all").Also adds all the scripts run in CI to
test_all.sh, plusdt_patches/dt_patch_test.sh.Leaves
@io_bazel_rules_scala_configas is for now, because it's a documented public interface. It can be easily changed and documented in a future commit if desired.Also doesn't change the
io_bazel_rules_scala_prefix for Maven artifact repos. This could also be done and documented in a future commit if desired.Motivation
This change enables
WORKSPACEand Bzlmod users to importrules_scalaasrules_scala, instead of requiringio_bazel_rules_scaladue to internal dependencies.i.e.,
WORKSPACEusers can still usehttp_archiveto importrules_scalaasio_bazel_rules_scala. Bzlmod users will be able to callbazel_dep(name = "rules_scala", repo_name = "io_bazel_rules_scala"). However,io_bazel_rules_scalais no longer required byrules_scalaitself.