bzlmod pip.parse default is leaking across to the other_module

[aignas]

In the bzlmod example, if you examine the @other_module_pip//absl_py:BUILD.bazel contents, you will see:

$ cat bazel-bzlmod/external/rules_python~override~pip~other_module_pip/absl_py/BUILD.bazel
package(default_visibility = ["//visibility:public"])

alias(
    name = "absl_py",
    actual = ":pkg",
)

alias(
    name = "pkg",
    actual = select(
        {
            "@@rules_python~override//python/config_settings:is_python_3.11.6": "@other_module_pip_311_absl_py//:pkg",
            "//conditions:default": "@other_module_pip_39_absl_py//:pkg",
        },
    ),
)

alias(
    name = "whl",
    actual = select(
        {
            "@@rules_python~override//python/config_settings:is_python_3.11.6": "@other_module_pip_311_absl_py//:whl",
            "//conditions:default": "@other_module_pip_39_absl_py//:whl",
        },
    ),
)

alias(
    name = "data",
    actual = select(
        {
            "@@rules_python~override//python/config_settings:is_python_3.11.6": "@other_module_pip_311_absl_py//:data",
            "//conditions:default": "@other_module_pip_39_absl_py//:data",
        },
    ),
)

alias(
    name = "dist_info",
    actual = select(
        {
            "@@rules_python~override//python/config_settings:is_python_3.11.6": "@other_module_pip_311_absl_py//:dist_info",
            "//conditions:default": "@other_module_pip_39_absl_py//:dist_info",
        },
    ),
)%

However, the other_module_pip does not have anything set up for 3.9 and is setting 3.11 as the default toolchain version for the sub-module. It seems that this line may be wrong and we need to get the default version per module that the extension is used in.

[rickeylev]

This is mostly WAI.

The basic issue is there can only be one default python version for the entire build. When the default py_binary rule is used (//python:py_binary.bzl), then its basically saying "The root module decides what Python version I'll run as".

This doesn't feel ideal, but I'm not sure there's much we can do. If a sub-module wants to support multiple python versions while not picking a particular python version, then it should create requirements for each version.

Also see: https://github.com/bazelbuild/rules_python/blob/main/examples/bzlmod/other_module/MODULE.bazel#L34

The is_default line has a comment saying it's ignored (because its not the root module). Silently ignoring isn't ideal, but I'm not sure what better options we have available. Rename it to is_default_if_root_module=True? The sub module does want it to be the default when doing development of the sub module itself, but we can't honor it when another root module is depending on other_module.

we need to get the default version per module that the extension is used in.

Creating a per-module specific default doesn't fix it because it results in a miss-match between the runtime and selected libraries. e.g. given

alias(name="pkg", actual=select({default: "other_module_pip_311_absl_py"}))

Then what would happen is Python 3.9 will be used as the runtime (via toolchain resolution), while a Python 3.11 package will be used as a dependency. This might work, depending on the circumstances, but is incorrect.

---

This also might be a remnant of a bug where -- I forget the exact details -- but something about how sub modules were required to specify a default, or required to include the default version the root module used. We fixed that by removing that validation logic.

---

The fix I recommend (and you see other_module use) is for a submodule, if it is pikcy about the Python version, to use the version-aware rules to ensure it gets the Python version it needs.

[aignas]

OK, then I think the change I propose in #1549 should make things more correct. I was thinking that maybe the render_pkg_aliases does not need to know about the default_version possible not being present in the versions, but given that the default can only be set by the root module, I think it makes sense to handle that edge case.

With #1549 the absl_py/BUILD.bazel now is:

$ cat bazel-bzlmod/external/rules_python~override~pip~other_module_pip/absl_py/BUILD.bazel
package(default_visibility = ["//visibility:public"])

_NO_MATCH_ERROR = """\
No matching wheel for current configuration's Python version.

The current build configuration's Python version doesn't match any of the Python
versions available for this wheel. This wheel supports the following Python versions:
    3.11.6

As matched by the `@rules_python~override//python/config_settings:is_python_<version>`
configuration settings.

To determine the current configuration's Python version, run:
    `bazel config <config id>` (shown further below)
and look for
    rules_python~override//python/config_settings:python_version

If the value is missing, then the "default" Python version is being used,
which has a "null" version value and will not match version constraints.
"""

alias(
    name = "absl_py",
    actual = ":pkg",
)

alias(
    name = "pkg",
    actual = select(
        {
            "@@rules_python~override//python/config_settings:is_python_3.11.6": "@other_module_pip_311_absl_py//:pkg",
        },
        no_match_error = _NO_MATCH_ERROR,
    ),
)

alias(
    name = "whl",
    actual = select(
        {
            "@@rules_python~override//python/config_settings:is_python_3.11.6": "@other_module_pip_311_absl_py//:whl",
        },
        no_match_error = _NO_MATCH_ERROR,
    ),
)

alias(
    name = "data",
    actual = select(
        {
            "@@rules_python~override//python/config_settings:is_python_3.11.6": "@other_module_pip_311_absl_py//:data",
        },
        no_match_error = _NO_MATCH_ERROR,
    ),
)

alias(
    name = "dist_info",
    actual = select(
        {
            "@@rules_python~override//python/config_settings:is_python_3.11.6": "@other_module_pip_311_absl_py//:dist_info",
        },
        no_match_error = _NO_MATCH_ERROR,
    ),
)