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

3 participants