Wrong Python version on Bazel 7 with WORKSPACE.bazel

[vonschultz]

🐞 bug report

Affected Rule

The issue is caused by the rule: py_binary

Is this a regression?

Yes, the previous version in which this bug was not present was: Bazel 6.5.0.

Description

When using Bazel 7.0.0 or 7.3.1 (and presumably others in that range), the system Python is used where the @rules_python//python/config_settings:python_version was previously respected (by Bazel 6.5.0) when running with a WORKSPACE file instead of a MODULE.bazel file. The rules_python/examples/multi_python_versions/ example in this very repository exhibits the problem, if you remove the MODULE.bazel* files and WORKSPACE.bzlmod.

This makes it difficult to upgrade to Bazel 7 first and do the MODULE.bazel migration after, which otherwise would seem like an attractive migration path.

🔬 Minimal Reproduction

Setup:

git clone https://github.com/bazelbuild/rules_python
cd rules_python/examples/multi_python_versions/
rm WORKSPACE.bzlmod MODULE.bazel*

By removing WORKSPACE.bzlmod and MODULE.bazel*, we're now in a situation with just a WORKSPACE file. The following command works, and correctly reports 3.11:

USE_BAZEL_VERSION=6.5.0 bazelisk run \
    --@rules_python//python/config_settings:python_version=3.11 //tests:version_default

When I test the same thing under Bazel 7.3.1 reports 3.10 (which is the system Python on Ubuntu 22) or 3.12 (which is the system Python on Ubuntu 24), depending on the system I run it on.

USE_BAZEL_VERSION=7.3.1 bazelisk run \
    --@rules_python//python/config_settings:python_version=3.11 //tests:version_default

🌍 Your Environment

Operating System:

  
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.1 LTS
Release:	24.04
Codename:	noble
  

Output of bazel version:

  
Bazelisk version: v1.20.0
Build label: 7.3.1
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Aug 19 16:12:50 2024 (1724083970)
Build timestamp: 1724083970
Build timestamp as int: 1724083970
  

Rules_python version:

  
commit 9a98e8c1f18fb8b1c41e1d409088da9c72cee352 (HEAD -> main, origin/main, origin/HEAD)
  

Anything else relevant?

Previously mentioned on https://bazelbuild.slack.com/archives/CA306CEV6/p1727352240596449

[aignas]

When on bazel 7.3.2, you also need to specify --noenable_bzlmod because by default bzlmod is going to be used.

The following will behave as you expect:

USE_BAZEL_VERSION=7.3.1 bazelisk run \
    --noenable_bzlmod \
    --@rules_python//python/config_settings:python_version=3.11 //tests:version_default

Because with bazel 7 onwards, it will create an empty MODULE.bazel file and if you don't specify explicitly to disable bzlmod the absence or presence of MODULE.bazel won't make a difference.

That said, I think the problem why it was falling back to the auto-detecting toolchain was because of #1675, which got fixed in #2289. By default rules_python was not registering any toolchains in WORKSPACE files when bzlmod is enabled and thus it would only know to fallback to the system python.

Closing as #2289 fixes this issue.