Good First Issues in Starlark

Support uv.lock in the Gazelle plugin Relevant Rules gazelle_python_manifest in //gazelle/manifest:defs.bzl Description The changes in #3952 to support #1975 have been helpful so far, thank you! I wanted to know if it would be possible to support uv_lock as an attr on gazelle_python_manifest as well, so that I can completely delete our requirements.lock.txt. Describe the solution you'd like Anything that will allow me to provide either uv_lock as an attr on gazelle_python_manifest instead of requirements, or something to totally obviate the manifest (as some other Gazelle plugins have managed to accomplish). Describe alternatives you've considered I haven't considered any alternatives, and I'm not super familiar with the constraints of this system (outside of having written a narrow Gazelle plugin of my own), so open to suggestions on the best way to approach this.

🚀 feature request Relevant Rules py_wheel (python/private/py_wheel.bzl) — extending an existing rule. Description py_wheel cannot produce a wheel whose METADATA conforms to PEP 639, which is now Final. On main today: Metadata-Version is hardcoded to 2.1 (python/private/py_wheel.bzl:422); the PEP 639 fields require 2.4. The only license-related attribute is the legacy free-text license (:250), emitted as the License: field (:432). PEP 639 deprecates that field. There is no way to emit License-Expression, no way to emit License-File, and no way to place license texts under <name>-<version>.dist-info/licenses/. There is no escape hatch for appending arbitrary METADATA lines either, so this cannot be worked around from a BUILD file. The practical impact is that a py_wheel cannot declare its license as an SPDX expression, and cannot ship the license texts of its bundled third-party dependencies in the location PEP 639 defines. For anyone who has to produce auditable license metadata

🚀 feature request Relevant Rules This is an extension of the existing pip.dep feature: https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/pip.html#pip.dep. Description pip.dep today is only used for abstract dependency management. The concrete dependencies still must come through pip.parse and a requirements.txt file. Describe the solution you'd like It would be nice to be able to specify dependencies / version requirements entirely in MODULE.bazel using pip.dep. This is similar to how the crate_universe feature works in rules_rust. Describe alternatives you've considered N/A

🚀 feature request Relevant Rules I would like to add support for passing additional files to the pip_parse rule. Description This feature request is a follow-up to #3858. After passing a custom certificate to compile_pip_requirements, we also need a way to pass a custom certificate, or another pip-related file (i.e. pip config with a certificate), to pip_parse. I tried to find a way to do this, but it looks like pip_parse does not currently accept data or another label-based attribute for passing extra files to the repository rule. Describe the solution you'd like I would like pip_parse to support an additional label-based attribute for files needed by pip, for example extra_files, pip_config, or ssl_cert. The most general option seems to be something like extra_files, because certificates can be passed to pip in more than one way: --cert=, PIP_CERT, or PIP_CONFIG_FILE. Describe alternatives you've considered The main alternative I considered is passing the pip config file or SSL ce

Problem I am trying to build TensorFlow on Windows ARM64 using Bazel/rules_python hermetic Python. Platform: OS: Windows ARM64 Target triple: aarch64-pc-windows-msvc Python: 3.13 ARM64 Bazel: 7.7.0 Build uses WORKSPACE / legacy pip_parse, not bzlmod TensorFlow initializes PyPI dependencies through pip_parse from: load("@rules_python//python:pip.bzl", "package_annotation", "pip_parse") pip_parse( name = "pypi", python_interpreter_target = "@python_3_13_host//:python", requirements_lock = REQUIREMENTS_WITH_LOCAL_WHEELS, envsubst = ["RULES_PYTHON_ENABLE_PIPSTAR"], # tried adding target platform settings, see below ) Observed behavior The generated file: external/pypi/requirements.bzl contains no packages: all_requirements = [] all_whl_requirements_by_package = {} all_data_requirements = [] _packages = [] This causes Bazel analysis failures later for normal TensorFlow deps such as: @pypi//wheel @pypi//gast because the @pypi repo is empty. The generated marker file: