Custom platform from `pip.default` can't be used by consumers

[Vooblin]

🐞 bug report

Affected Rule

The issue is caused by the bzlmod module extension pip in the pip.default / pip.parse tag handling in:

• python/private/pypi/extension.bzl (build_config())
• python/private/pypi/parse_requirements.bzl (MacOS, _package_srcs())
• python/private/pypi/hub_builder.bzl (Ubuntu, _evaluate_markers())

Is this a regression?

No.

Description

When pip.default() is called from a non-root Bazel module (a dependency module), it is ignored while building the pip extension config. At the same time, pip.parse() in that dependency module is still processed and can create a hub repo that the consumer can use transitively.

This makes it impossible (or very confusing) for a dependency module to ship a reusable pip.parse() hub that relies on custom platforms defined by that same module’s pip.default().

Expected behavior

pip.default() platform definitions from a dependency module are applied at least for that module’s own pip.parse() tags.

Actual behavior

• pip.default() from dependency modules is ignored.
• pip.parse() from dependency modules is processed.
• If pip.parse() needs a custom platform, evaluation will fail with an error.
• Workaround today: the root module must re-declare the same platforms in its own pip.default().

🔬 Minimal Reproduction

Reproduction repository: https://github.com/Vooblin/pip-default-bug

🔥 Exception or Error

• MacOS: The target platform 'cp312.12_plat_a' could not be found in ["cp312.12_linux_x86_64", "cp312.12_linux_aarch64", "cp312.12_osx_aarch64", "cp312.12_osx_x86_64", "cp312.12_windows_x86_64", "cp312.12_windows_aarch64"]
• Linux: Error: key "cp312.12_plat_a" not found in dictionary

🌍 Your Environment

Operating System

MacOS 26.1, Ubuntu 24.04

Output of bazel version

7.5.0

Rules_python version

1.7.0

Anything else relevant

None.

References

None.

[aignas]

I am thinking that this is a valid feature request - pip.parse invocations in non-root module should not break if they rely on custom platforms. However, We should not change the pip.default - the pip.configure should be implemented instead so that we have the correct semantics. pip.default was created only for rules_python and/or root modules, so this is working as intended, but you are hitting missing APIs/implementation elsewhere in the codebase.