Good First Issues in Starlark

🐞 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

rustc actions advertise supports-path-mapping, but the C++ linker returned by cc_common.get_tool_for_action() is passed to rustc as an analysis-time string: rustc_flags.add(ld, format = "--codegen=linker=%s") The C++ link arguments are also passed as strings: rustc_flags.add_all(link_args, format_each = "--codegen=link-arg=%s") Bazel only rewrites paths that retain their File identity when expanded through an Args object. It cannot rewrite arbitrary strings containing file.path. When --experimental_output_paths=strip is enabled, the Rustc action executes against the path-mapped bazel-out/cfg layout, but --codegen=linker and linker arguments such as --sysroot can still refer to their analysis-time bazel-out/<configuration>-exec paths. This causes Rust linking to fail when using a hermetic C++ toolchain whose linker or sysroot is a Bazel artifact. Example failure The generated Rustc command contains arguments similar to: --codegen=linker=bazel-out/<configuration>-exec/bin/.../x86_64-linu

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

rules_rust forwards Apple C++ toolchain linker args to rustc, including clang targets like: -C link-arg=-target -C link-arg=arm64-apple-macosx26.0 When developing on macOS, these linker arguments commonly come from the Xcode toolchain created by apple_support. With apple_support, the minimum deployment version defaults to whatever the installed SDK version is. That target argument encodes the Apple deployment target for clang. However, rustc does its own minimum deployment target detection. This is mediated through the MACOSX_DEPLOYMENT_TARGET env variable. If MACOSX_DEPLOYMENT_TARGET is unset, rustc uses its built-in default and injects its own -mmacosx-version-min (which defaults to 11.0.0 on arm64) Source: https://doc.rust-lang.org/nightly/rustc/platform-support/apple-darwin.html#deployment-target This can make clang receive conflicting deployment targets, for example: -mmacosx-version-min=11.0.0 -target arm64-apple-macosx26.0 With Rust 1.97 surfacing linker stderr, this issue is

🚀 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:

Is your feature request related to a problem? Please describe. https://github.com/bazel-contrib/rules_img is similar to rules_oci in spirit, but has much nicer optimizations. Describe the solution you'd like Add an example using rules_img equivalent to what is described in haskell-use-cases.rst and also update the documentation. Describe alternatives you've considered Additional context

🐞 bug report Affected Rule runfiles Is this a regression? No Description PyCharm's Python console adds some stuff to the import path including a runfiles module. So when users open a project that supports both Bazel and virtual environments using this console, they run into errors like >>> import mytest Traceback (most recent call last): File "<input>", line 1, in <module> File "/Applications/PyCharm.app/Contents/plugins/python-ce/helpers/pydev/_pydev_bundle/pydev_import_hook.py", line 21, in do_import module = self._system_import(name, *args, **kwargs) File "/tmp/PythonProject/mytest/__init__.py", line 1, in <module> from runfiles import Runfiles ImportError: cannot import name 'Runfiles' from 'runfiles' (/Applications/PyCharm.app/Contents/plugins/python-ce/helpers/pydev/runfiles.py) There doesn't seem to be any way around this other than wrapping from runfiles import Runfiles in some try/except or similar, which is unfortunate. What if we had the bazel-runfiles pack

When upgrading to rules_rust 0.66 from 0.65 we see this error: D:\workdir\gitlab\plm\tc\servicemesh>bazel build //... INFO: Analyzed 229 targets (2186 packages loaded, 86137 targets configured). ERROR: D:/udu/b/jsuyf6jg/external/rules_rust+/cargo/private/BUILD.bazel:4:12: Compiling Rust bin copy_file (1 files) [for tool] failed: (Exit 1): process_wrapper.exe failed: error executing Rustc command (from target @@rules_rust+//cargo/private:copy_file) bazel-out\x64_windows-opt-exec-ST-ec4a08ce3b65\bin\external\rules_rust+\util\process_wrapper\process_wrapper.exe --subst pwd=${pwd} -- ... (remaining 55 arguments skipped) error: linking with `external/tc_toolchain+/toolchain/x64-windows/14.42.34433/link.exe` failed: exit code: 1181 | = note: "external/tc_toolchain+/toolchain/x64-windows/14.42.34433/link.exe" "/NOLOGO" "C:\\Users\\browchri.PLM\\AppData\\Local\\Temp\\rustclVmcWj\\symbols.o" "<2 object files omitted>" "<sysroot>\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib/{libstd-*,libpanic_

🐞 bug report Affected Rule The issue is caused by the rule: python = use_extension("@rules_python//python/extensions:python.bzl", "python") Loading python seems to check the system python version. This makes it impossible to use rules_python if the version is not in its version dict: File "$BUILD/external/rules_python+/python/private/python_register_toolchains.bzl", line 106, column 31, in python_register_toolchains sha256 = tool_versions[python_version]["sha256"].get(platform, None) Error: key "3.14.0b2" not found in dictionary ERROR: Analysis of target '@@rules_python+//python/bin:repl' failed; build aborted: error evaluating module extension @@rules_python+//python/extensions:python.bzl%python Note that this happens when loading the python extension, which is required to configure the python version, creating a catch 22. Is this a regression? I have found other occurrences (1,2) of the error message (as below) but I don't think it was traced to this