1.5.0 breaks Bazel 7 WORKSPACE builds

[mbland]

🐞 bug report

Affected Rule

py_binary, py_test, and py_library in 1.5.0 and 1.5.1.

Is this a regression?

Yes. It was not present in 1.4.1, but is present in 1.5.0.

Description

Bazel 7.6.1 will use the builtin PyRuntimeInfo when building under WORKSPACE. The PyRuntimeInfo.supports_build_time_venv field (added in #2760) breaks, since it exists in rules_python 1.5.0 and 1.5.1, but doesn't exist in the builtin provider.

WORKSPACE builds work with Bazel 8.0.0 and 8.3.1. Bzlmod builds work with Bazel 7.6.1.

🔬 Minimal Reproduction

WORKSPACE:

workspace(name = "pyruntimeinfo_breakage")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "rules_python",
    sha256 = "7b9039c31e909cf59eeaea8ccbdc54f09f7ebaeb9609b94371c7de45e802977c",
    strip_prefix = "rules_python-1.5.0",
    url = "https://github.com/bazel-contrib/rules_python/releases/download/1.5.0/rules_python-1.5.0.tar.gz",
)

load("@rules_python//python:repositories.bzl", "py_repositories")

py_repositories()

MODULE.bazel (optional):

module(name = "pyruntimeinfo_breakage")

bazel_dep(name = "rules_python", version = "1.5.0")

BUILD:

load("@rules_python//python:py_binary.bzl", "py_binary")

py_binary(
    name = "example",
    srcs = ["example.py"],
)

Then run:

touch example.py
USE_BAZEL_VERSION=7.6.1 bazel build --enable_workspace --noenable_bzlmod //...

🔥 Exception or Error

$ USE_BAZEL_VERSION=7.6.1 bazel build --enable_workspace --noenable_bzlmod //...

Starting local Bazel server and connecting to it...
ERROR: BUILD:3:10: in py_binary rule //:example: 
Traceback (most recent call last):
        File ".../external/rules_python/python/private/py_binary_rule.bzl", line 24, column 30, in _py_binary_impl
                return py_executable_impl(
        File ".../external/rules_python/python/private/py_executable.bzl", line 255, column 35, in py_executable_impl
                return py_executable_base_impl(
        File ".../external/rules_python/python/private/py_executable.bzl", line 1140, column 46, in py_executable_base_impl
                exec_result = semantics.create_executable(
        File ".../external/rules_python/python/private/py_executable.bzl", line 365, column 33, in _create_executable
                _create_stage1_bootstrap(
        File ".../external/rules_python/python/private/py_executable.bzl", line 809, column 27, in _create_stage1_bootstrap
                if runtime and runtime.supports_build_time_venv:
Error: 'PyRuntimeInfo' value has no field or method 'supports_build_time_venv'
Available attributes: bootstrap_template, coverage_files, coverage_tool, files, interpreter, interpreter_path, python_version, stub_shebang
ERROR: BUILD:3:10: Analysis of target '//:example' failed
ERROR: Analysis of target '//:example' failed; build aborted

🌍 Your Environment

Operating System:

  
$ uname -mrs

Darwin 24.5.0 arm64
  

Output of bazel version:

  
$ USE_BAZEL_VERSION=7.6.1 bazel version

Bazelisk version: 1.26.0
Starting local Bazel server and connecting to it...
Build label: 7.6.1
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Mar 31 17:11:07 2025 (1743441067)
Build timestamp: 1743441067
Build timestamp as int: 1743441067
  

Rules_python version:

  
$ grep -- '"rules_python-' WORKSPACE

    strip_prefix = "rules_python-1.5.0",
  

Anything else relevant?

I encountered this while building bazel-contrib/rules_scala using Bazel 7.6.1 in WORKSPACE mode after upgrading to rules_python 1.5.1.

Trying --incompatible_autoload_externally with either +@rules_python or +PyRuntimeInfo breaks with the same error, but preceded with the warning:

WARNING: Couldn't auto load rules or symbols,
  because no dependency on module/repository 'rules_python' found.
  This will result in a failure if there's a reference to those rules or symbols.

Nothing I could do could avoid using the builtin PyRuntimeInfo under Bazel 7.6.1 when building under WORKSPACE.

[aignas]

This is weird, we do have CI that is testing workspace builds for bazel 7 - https://github.com/bazel-contrib/rules_python/blob/main/.bazelci/presubmit.yml#L42

I wonder why that is the case.

[mbland]

Well, I just went digging around and found python/private/internal_config_repo.bzl, and you know what I found works?

$ USE_BAZEL_VERSION=7.6.1 bazel build --enable_workspace --noenable_bzlmod \
   --repo_env=RULES_PYTHON_ENABLE_PYSTAR=0 //...

INFO: Analyzed target //:example (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:example up-to-date:
  bazel-bin/example
INFO: Elapsed time: 0.058s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

But when I set RULES_PYTHON_ENABLE_PYSTAR=1, which is the default, it goes boom in the same way as before. (Expected, since that's the default.)

[mbland]

Something else odd about the Default: Ubuntu, workspace, minimum Bazel on :ubuntu: Ubuntu 22.04 LTS job:

• --noenable_bzlmod appears on line 277
• --enable_bzlmod appears on line 284, as if it overrides the previous flag:

(04:43:46) INFO: Reading rc options for 'build' from /workdir/.bazelrc:
  Inherited 'common' options: --incompatible_disallow_struct_provider_syntax --enable_bzlmod --incompatible_python_disallow_native_rules

[mbland]

Hmm, the Buildkite log might be a bit of a red herring. But something's going on with RULES_PYTHON_ENABLE_PYSTAR. Related items include:

• feat: enable rules_python Starlark implemention by default for Bazel 7+ #1699
• bug: PyRuntimeInfo provided by py_binary doesn't match PyRuntimeInfo symbol from rules_python #1732
• fix(PyRuntimeInfo): use builtin PyRuntimeInfo unless pystar is enabled. #1748
• RULES_PYTHON_ENABLE_PYSTAR documentation source
• RULES_PYTHON_ENABLE_PYSTAR access in python/private/internal_config_repo.bzl

[aignas]

I have a suspicion that the autoloading in bazel may have something to do with it. The version that bazel 7.6.1 has is very old and if I remember correctly the code that added handling of the providers correctly was added later.

The problem with fixing this is that it is very hard adding CI for it, because when running the tests locally, everything works.

[mbland]

I suspected it had to be something like that. Just wanted to get it on the record, at least, even if there isn't a proper fix forthcoming.