feat(pypi): add native local wheel override support to bzlmod pip.parse

[meteorcloudy]

This feature allows developers to easily test locally built Python wheels (e.g., wheels built locally before running integration tests) without needing to publish them to an index or manually edit requirements_lock.txt.

This is a proper implementation of the local_wheel_dist_folder feature used in JAX/TF/XLA.

• https://github.com/jax-ml/jax/blob/d72694890a8dd1911435edc8f5732af0c58054f5/WORKSPACE#L50-L62
• https://github.com/google-ml-infra/rules_ml_toolchain/blob/11bbb592cb4d7cbc8ae07d6a4e5ad58ee38605f2/py/python_repo.bzl

How to Use

In your MODULE.bazel file, configure pip.parse with the new local_wheels dictionary mapping:

pip = use_extension("@rules_python//python/extensions:pip.bzl", "pip")

pip.parse(
    hub_name = "pip",
    python_version = "3.15",
    requirements_lock = "//:requirements_lock.txt",
    experimental_index_url = "https://pypi.org/simple",
    local_wheels = {
        "my_package": "dist/my_package-0.1.0-py3-none-any.whl",
        "libtpu": "dist/libtpu-*.whl",
    },
)

Details

• Maps individual package names to local wheel paths relative to your workspace root. Supports middle wildcards (e.g. dist/libtpu-*.whl) and automatically selects the newest version if multiple matching wheels exist. Silently falls back to remote PyPI if the local file is missing.
• Discovery the workspace root via @@//:MODULE.bazel
• Effective only when pip.parse is evaluated by the root module.
• Effective only when index_url is used (which is now by default)

[gemini-code-assist]

Code Review

This pull request introduces support for overriding PyPI dependencies with local wheels located in a specified distribution folder, restricted to the root module. It adds new attributes to the pip extension for specifying the distribution folder and inclusion/exclusion patterns, implements logic to collect and filter local wheels based on ABI markers, and updates the wheel repository generation to use local file URLs. Feedback from the review highlights potential issues with ABI marker generation when patch versions are present and warns against using lexicographical sorting to resolve multiple matching wheels, suggesting instead to fail on ambiguity.

[aignas]

I have some concerns about this short-circuiting the wheel selection algorithm used in parse_requirements so left a few ideas.

[aignas]

Suggested change

	:::{versionadded} 2.1.0
	:::{versionadded} VERSION_NEXT_FEATURE

[aignas]

This is great to have, but having a few comments would be good.

[aignas]

Please add a docstring with typing information

[aignas]

Is this path_str absolute? We could as well use whl_file attribute and pass a label if we were ever able to construct one.

Note to myself - because we are not getting this from pypi_cache.bzl, this will never go into the lock file, which means that whether it is absolute or not does not matter that much.

[aignas]

This relies on lexicographic sorting, but it may be better to:

1. parse the wheel name (with //python/private:parse_whl_name.bzl or similar)
2. get the version component
3. parse the version component (with //python/private:version.bzl)
4. Do the version comparison.

What do we do if we match multiple abis, platforms? Should we use the select_whl function from parse_requirements.bzl to actually match the right wheel based on target platform?

Maybe the right way would be to actually override the get_index function in case it is a root module to replace the wheels found on the internet with the wheels found locally and then let the wheel selection algorithm do the right thing instead of doing the wild card matching here and this comparison.