bazel-contrib/rules_python

🐞 bug report Affected Rule pip.parse Is this a regression? not that I can tell Description pip.parse with uv_lock fails when the lock file contains a package with a git source entry with a rev hash due to the url in the lock file being used as the literal download url. 🔬 Minimal Reproduction same as #4084 pyproject.toml ... mypackage = { git = "https://github.com/foo/bar", rev = "6323b05075dcb2347279e966a5a3b15b5ddc1d5b" } ... uv.lock ... [[package]] name = "mypackage" version = "0.0.1" source = { git = "https://github.com/foo/bar?rev=6323b05075dcb2347279e966a5a3b15b5ddc1d5b#6323b05075dcb2347279e966a5a3b15b5ddc1d5b" } dependencies = [ ... ] ... Resulting in https://github.com/foo/bar?rev=6323b05075dcb2347279e966a5a3b15b5ddc1d5b#6323b05075dcb2347279e966a5a3b15b5ddc1d5b being used as the download url in rules_python/python/private/pypi/pip_archive.bzl Lines 263 to 269 in b1b9bf0 resul

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