Skip to content

Conversation

aignas
Copy link
Collaborator

@aignas aignas commented Jul 10, 2025

  • use the SHA256SUMS file instead of individual sha256sum files. This
    improves the speed of the tooling and also the old files just
    disappeared for the latest toolchain release.
  • update to the latest release.

@aignas aignas requested a review from rickeylev as a code owner July 10, 2025 14:25
@rickeylev
Copy link
Collaborator

CVE-2025-47273 is a vuln in setuptools, how does the interpreter address it?

- use the SHA256SUMS file instead of individual sha256sum files. This
  improves the speed of the tooling and also the old files just
  disappeared for the latest toolchain release.
- update to the latest release.
@aignas aignas force-pushed the chore-update-standalone-release branch from 00125dc to 81e5bdd Compare July 11, 2025 09:16
@aignas
Copy link
Collaborator Author

aignas commented Jul 11, 2025

This is because setuptools get bundled with the interpreter.

@aignas aignas enabled auto-merge July 11, 2025 09:20
@aignas aignas added this pull request to the merge queue Jul 15, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to a conflict with the base branch Jul 15, 2025
@aignas aignas added this pull request to the merge queue Jul 15, 2025
@aignas aignas removed this pull request from the merge queue due to a manual request Jul 15, 2025
@aignas aignas enabled auto-merge July 15, 2025 02:42
@aignas aignas added this pull request to the merge queue Jul 15, 2025
Merged via the queue into bazel-contrib:main with commit 9555ba8 Jul 15, 2025
3 checks passed
@scasagrande
Copy link
Contributor

can we get this cherry picked onto 1.5 to resolve the CVE?

@rickeylev
Copy link
Collaborator

That's a good idea.
I think the python.override apis can also be used to switch up which tar.gz is used

@scasagrande
Copy link
Contributor

Yeah I finally tracked down where my cve alert was coming from and now I'm using python.override to pick up these new versions.

But releasing a patch version of rules_python will make the fix more likely to be picked up by everyone

@aignas aignas deleted the chore-update-standalone-release branch July 17, 2025 04:08
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
mbland added a commit to mbland/rules_scala that referenced this pull request Aug 15, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from bazel-contrib#1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
simuons pushed a commit to bazel-contrib/rules_scala that referenced this pull request Aug 18, 2025
Fixes the runfiles problems with Windows builds for Bazel 8 and later
seen in bazelbuild/bazel-central-registry#5490. Bumps a number of
dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from
`7.1.0` to `7.1.1`.

Dependency version bumps include:

- Go: 1.24.5 => 1.25.0
- `golang.org/x/tools`: v0.35.0 => v0.36.0
- `jline`: 3.30.4 => 3.30.5
- `protobuf-java`: 4.31.1 => 4.32.0
- `protobuf`: v31.1 => v32.0
- `rules_java`: 8.15.0 => 8.15.1
- `rules_python`: 1.5.2 => 1.5.3

Also:

- Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing
  the change from #1760.

- Fixes precompiled Windows protoc selection on ARM64 in
  `protoc/private/protoc_toolchains.bzl`.

- Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner
  implementation.

- Removes `rules_jvm_external` from `scala/latest_deps.bzl`.

---

bazelbuild/continuous-integration#2350 resolved the Windows symlink
problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7
Windows build. This enables the restoration of the original
`examples/crossbuild/protobuf.patch` symlink, effectively closing
bazelbuild/bazel-central-registry#5506.

The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes
fix the remaining bazelbuild/bazel-central-registry#5490 breakages.
Specifically, adding the `.exe` suffix only when necessary under Bazel 7
fixes the Windows builds for Bazel 8 and later. However, we'll have to
close that pull request and push the v7.1.1 tag to begin a new release.

The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc.
are from the `com.google.devtools.build.Runfiles` docstring:

- https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134

`RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles
library usage, and technically became obsolete in commit
f758956.

Instantiating `rules_jvm_external` ourselves is no longer necessary
because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which
closed protocolbuffers/protobuf#19129.

I've tested this change using my personal Windows 11 ARM64 virtual
machine, hence the updates to `protoc/private/protoc_toolchains.bzl`.
Previously, the `exec_compatible_with` attribute of the toolchain target
contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`.
This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve
to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering
recompilation.

I also had to use `python.single_version_platform_override` and to fix
`@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is
because the latest `rules_python` 1.5.3 doesn't contain any entries for
`aarch64-pc-windows-msvc` in `//python:versions.bzl`.

However, it appears such entries are coming in the next `rules_python`
release, which will eliminate the need for such a workaround. For that
reason, I haven't tried to include it in this change.

- https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138
- https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl
- https://github.com/astral-sh/python-build-standalone/releases/
- https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override
- bazel-contrib/rules_python#2276
- bazel-contrib/rules_python#3062
- bazel-contrib/rules_python#3074
- bazel-contrib/rules_python#3116

A couple of interesting new facts I learned about `protobuf` in the
process of producing this change:

- v32.0 officially drops support for Bazel 6:
  https://github.com/protocolbuffers/protobuf/releases/tag/v32.0
  protocolbuffers/protobuf@da0077e

- v34 isn't dropping MSVC support after all:
  https://protobuf.dev/news/2025-07-16/
  protocolbuffers/protobuf#20085
  protocolbuffers/protobuf#20085 (comment)
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

Successfully merging this pull request may close these issues.

3 participants