[Spikhalskiy]

Python version transitions also reach native dependencies that don't use Python, so a C++ or Rust library under bindings for several Python versions is configured once per version. Add a root-module python_config extension whose python_version_scope(scope = "project") tag gives @aspect_rules_py//py:python_version Bazel's project scope, delegating ownership to the consumer's //:PROJECT.scl. Under project scope the flag and the internal baseline flags that terminals use to restore the inherited version are aliases to project-scoped flags in the generated config repository; otherwise targets outside the project would still split on the baselines. Bazel reads the project file of every top-level target's package, so only the opt-in ships the forwarding PROJECT.scl, and other builds need no root PROJECT.scl. Without the tag nothing changes, and tags from dependency modules are ignored. The extension is independent of interpreter provisioning, so users of other interpreter rulesets can opt in too.

Project scope requires Bazel 9.2 or later, the first release that keeps project-scoped flags across exec transitions (bazelbuild/bazel#28320); older versions fail with an explicit error. Terminals also set rules_python's version flag, so native dependencies fully converge only with rules_python's matching opt-in, bazel-contrib/rules_python#4377.

The default scope is unchanged, so on Bazel 10 exec tools still lose the version unless a scope is chosen; #1539 addresses that default separately.

The e2e fixture applies the terminals' transition and checks target and exec propagation, that transitioned and untransitioned paths give the native dependency the same rules_py settings, and that a duplicate tag is rejected.

Fixes #1649

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[dzbarsky]

This doesn't make a lot of sense to me from an OSS consumer POV. See also https://bazelbuild.slack.com/archives/CA306CEV6/p1793353806583359?thread_ts=1790099836.650159&cid=CA306CEV6

[Spikhalskiy]

@dzbarsky could you please elaborate what doesn't make sense? Is it this specific PR or the motivation?
We use this diff internally to work around effectively bazelbuild/bazel#13281 by enabling project scoping and stripping unrelated (python-related) configs from native targets in the graph and avoiding cache misses. We are an OSS user. So I'm just looking for a way to productize it and expose as a supported feture.

I'm not in Bazel slack yet, will figure my way in.