Skip to content

build: add flag_alias definition for Starlarkification of python flags #3450

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
aranguyen wants to merge 15 commits into
base: main
Choose a base branch
from
+10 −4
Open

build: add flag_alias definition for Starlarkification of python flags #3450

Show file tree
Hide file tree
Changes from 7 commits
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
7b52502
add flag_alias definition for Starlarkification of python flags
aranguyen Dec 10, 2025
e9688b7
Merge branch 'main' into main
rickeylev Dec 14, 2025
15687f1
Merge branch 'bazel-contrib:main' into main
aranguyen Dec 18, 2025
5c6539e
fix error
aranguyen Dec 18, 2025
504ccf3
use starlark flags instead
aranguyen Dec 18, 2025
effbe4c
fix starlark label
aranguyen Dec 18, 2025
e7bc464
remove extra character
aranguyen Dec 18, 2025
ee233fd
Merge branch 'bazel-contrib:main' into main
aranguyen Jan 12, 2026
84439af
use common label
aranguyen Jan 12, 2026
3c53c52
remove incorrect label
aranguyen Jan 12, 2026
0dbccff
update bazel version to 7.7.0
aranguyen Jan 13, 2026
0c7134c
fix
aranguyen Jan 14, 2026
7106a6b
update bazel version to 8.5.1 where flag_alias is backported as no-op
aranguyen Jan 14, 2026
e630cb8
add back the native flag reference as that is needed
aranguyen Jan 14, 2026
25895ab
add the correct flags
aranguyen Jan 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions MODULE.bazel
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -458,3 +458,8 @@ uv_dev = use_extension(
uv_dev.configure(
version = "0.6.2",
)

flag_alias(name = "build_python_zip", starlark_flag = "//python/config_settings:build_python_zip")
flag_alias(name = "incompatible_default_to_explicit_init_py", starlark_flag = "//python/config_settings:incompatible_default_to_explicit_init_py")
flag_alias(name = "python_path", starlark_flag = "//python/config_settings:python_path")
flag_alias(name = "experimental_python_import_all_repositories", starlark_flag = "//python/config_settings:experimental_python_import_all_repositories")
Comment on lines +464 to +467
Copy link
Contributor

@shayanhoshyari shayanhoshyari Jan 8, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will this work for users of rules_python too?
otherwise I think this issue still stands : #3252 (comment)

Copy link
Contributor

@gregestren gregestren Jan 8, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should work today, even before this PR is submitted.

Bazel 9 hard-codes those aliases right now. Once this PR works we'll remove the hard-coded logic from bazel@head.

The intention is users should have a seamless experience regardless of what's going on behind the scenes.

Copy link
Contributor

@shayanhoshyari shayanhoshyari Jan 8, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I read https://docs.google.com/document/d/1yOvi4hVV7Ja32ocwVb4lsEUnijftk8nilXPncYm-BH8/edit?tab=t.0#heading=h.mfw8nr4w6amb briefly, and as you say this trickles down to users too, and not just rules_python. Makes sense.

Now another question, by adding this PR, should this code just be removed now?

rules_python/python/private/flags.bzl

Lines 39 to 73 in 144984c

_POSSIBLY_NATIVE_FLAGS = {
"build_python_zip": (lambda ctx: ctx.fragments.py.build_python_zip, "native"),
"default_to_explicit_init_py": (lambda ctx: ctx.fragments.py.default_to_explicit_init_py, "native"),
"python_import_all_repositories": (lambda ctx: ctx.fragments.bazel_py.python_import_all_repositories, "native"),
"python_path": (lambda ctx: ctx.fragments.bazel_py.python_path, "native"),
}
def read_possibly_native_flag(ctx, flag_name):
"""
Canonical API for reading a Python build flag.
Flags might be defined in Starlark or native-Bazel. This function reasd flags
from tbe correct source based on supporting Bazel version and --incompatible*
flags that disable native references.
Args:
ctx: Rule's configuration context.
flag_name: Name of the flag to read, without preceding "--".
Returns:
The flag's value.
"""
# Bazel 9.0+ can disable these fragments with --incompatible_remove_ctx_py_fragment and
# --incompatible_remove_ctx_bazel_py_fragment. Disabling them means bazel expects
# Python to read Starlark flags.
use_native_def = hasattr(ctx.fragments, "py") and hasattr(ctx.fragments, "bazel_py")
# Developer override to force the Starlark definition for testing.
if _POSSIBLY_NATIVE_FLAGS[flag_name][1] == "starlark":
use_native_def = False
if use_native_def:
return _POSSIBLY_NATIVE_FLAGS[flag_name][0](ctx)
else:
# Starlark definition of "--foo" is assumed to be a label dependency named "_foo".
(from #3290) and just the rules_python config be read instead? Because the flag_alias is already doing (and even a better job) than what this code is trying to do.

Copy link
Contributor

@gregestren gregestren Jan 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should still be necessary so rules_python remains compatible with bazel 7 and 8, which can't resolve the flag aliases. Whenever rules_python drops support for pre-9 bazel we can remove this code.

2 changes: 1 addition & 1 deletion tests/base_rules/py_executable_base_tests.bzl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ def _test_basic_zip(name, config):
# platforms.
# Pass value to both native and starlark versions of the flag until
# the native one is removed.
"//command_line_option:build_python_zip": "true",
"//python/config_settings:build_python_zip": "true",
Copy link
Contributor

@shayanhoshyari shayanhoshyari Jan 10, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gregestren sorry for ping again. Are you sure this is a correct change on bazel 7 and 8?

My understanding is that

  • you mentioned flag alias is no op on these versions.
  • and the code here

    rules_python/python/private/flags.bzl

    Lines 39 to 73 in 144984c

    _POSSIBLY_NATIVE_FLAGS = {
    "build_python_zip": (lambda ctx: ctx.fragments.py.build_python_zip, "native"),
    "default_to_explicit_init_py": (lambda ctx: ctx.fragments.py.default_to_explicit_init_py, "native"),
    "python_import_all_repositories": (lambda ctx: ctx.fragments.bazel_py.python_import_all_repositories, "native"),
    "python_path": (lambda ctx: ctx.fragments.bazel_py.python_path, "native"),
    }
    def read_possibly_native_flag(ctx, flag_name):
    """
    Canonical API for reading a Python build flag.
    Flags might be defined in Starlark or native-Bazel. This function reasd flags
    from tbe correct source based on supporting Bazel version and --incompatible*
    flags that disable native references.
    Args:
    ctx: Rule's configuration context.
    flag_name: Name of the flag to read, without preceding "--".
    Returns:
    The flag's value.
    """
    # Bazel 9.0+ can disable these fragments with --incompatible_remove_ctx_py_fragment and
    # --incompatible_remove_ctx_bazel_py_fragment. Disabling them means bazel expects
    # Python to read Starlark flags.
    use_native_def = hasattr(ctx.fragments, "py") and hasattr(ctx.fragments, "bazel_py")
    # Developer override to force the Starlark definition for testing.
    if _POSSIBLY_NATIVE_FLAGS[flag_name][1] == "starlark":
    use_native_def = False
    if use_native_def:
    return _POSSIBLY_NATIVE_FLAGS[flag_name][0](ctx)
    else:
    # Starlark definition of "--foo" is assumed to be a label dependency named "_foo".
    will always pick the py_fragments values and ignore the rules_python configs for bazel 7 and 8.

So the result is this change to overrides on these bazel versions will make the override stop overriding anything, breaking the test.

I see in CI failures like below that probably is related

(18:22:56) ERROR: /workdir/tests/config_settings/transition/BUILD.bazel:6:25: On dependency edge //tests/config_settings/transition:test_py_binary_windows_build_python_zip_false (722907e) -|target|-> //tests/config_settings/transition:test_py_binary_windows_build_python_zip_false_subject: com.google.devtools.build.lib.packages.BuildFileNotFoundException: no such package '@@rules_testing//python/config_settings': BUILD file not found in directory 'python/config_settings' of external repository @@rules_testing. Add a BUILD file to a directory to mark it as a package.
(18:22:56) ERROR: Analysis of target '//tests/config_settings/transition:test_py_binary_windows_build_python_zip_false' failed; build aborted

Copy link
Author

@aranguyen aranguyen Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @shayanhoshyari , taking a closer look at the error no such package '@@rules_testing//python/config_settings': BUILD file not found in directory 'python/config_settings' of external repository @@rules_testing

I'm wondering if this is just changing this from "//python/config_settings:build_python_zip": "true", to "@@rules_python//python/config_settings:build_python_zip": "true",?

The code seems to be looking for this flag definition in package @@rules_testing

Copy link
Author

@aranguyen aranguyen Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and probably update @@rules_testing to depends on the newer version of @rules_python that has these flag def? https://github.com/bazelbuild/rules_testing/blob/master/MODULE.bazel#L19

labels.BUILD_PYTHON_ZIP: True,
"//command_line_option:cpu": "linux_x86_64",
"//command_line_option:crosstool_top": CROSSTOOL_TOP,
Expand Down
2 changes: 1 addition & 1 deletion tests/config_settings/transition/multi_version_tests.bzl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,7 +92,7 @@ def _setup_py_binary_windows(name, *, impl, build_python_zip):
target = name + "_subject",
impl = impl,
config_settings = {
"//command_line_option:build_python_zip": str(build_python_zip),
"//python/config_settings:build_python_zip": str(build_python_zip),
labels.BUILD_PYTHON_ZIP: build_python_zip,
"//command_line_option:extra_toolchains": CC_TOOLCHAIN,
"//command_line_option:platforms": str(platform_targets.WINDOWS_X86_64),
Expand Down