Starlark good first issues

The user is reporting that code coverage reports are only generated for Scala files when their directory structure has a specific depth relative to the BUILD file. Files are excluded from coverage results if they are nested too deeply or if the BUILD file is not at the root. This issue appears to be specific to code coverage and not other build/test operations.

This issue reports a bug where packages locked from a Git source in a `uv.lock` file are not correctly handled by `pip.parse`. The problem arises because the URL in the lock file, which includes Git parameters like `rev`, is being treated as a literal download URL, leading to fetch and validation errors.

This issue requests an update to the `py_wheel` rule to support PEP 639 license metadata. This involves adding support for SPDX license expressions and license files, which are crucial for auditable license metadata in redistributed wheels. The proposed solution includes new attributes for `license_expression` and `license_files`, and a backward-compatible update to the metadata version.

This issue describes a problem where Bazel's path mapping for hermetic C++ toolchains is not correctly applied to arguments passed to `rustc`. Specifically, the C++ linker path and sysroot paths are passed as analysis-time strings, which Bazel cannot rewrite. This leads to Rust linking failures when the toolchain is a Bazel artifact, as the sandbox environment uses a different path layout.

This issue requests adding support for `uv_lock` as an attribute to the `gazelle_python_manifest` rule. The goal is to allow users to fully replace `requirements.lock.txt` files with `uv_lock` files, simplifying dependency management within the Gazelle plugin.

The `pip.parse` function in `uv_lock` fails when parsing lock files containing Git-sourced packages with a revision hash. This is because the generated repository name includes a '?' character, which is invalid for Bazel repository names.

This issue describes a bug where rules_distroless fails to decompress xz package indices on macOS because it relies on the `xz` command, which is not natively available. The native macOS decompression method for xz files is `gzip -d`, and the issue suggests either automatically using this or at least documenting the `xz` dependency.

The `build_test` macro in bazel-skylib uses an internal rule named `_empty_test`, which is not descriptive when filtering targets. The issue proposes renaming this internal rule to `skylib_build_test` for better clarity and user experience.

The `pip_parse` tool in Bazel's `rules_python` is failing to generate PyPI package definitions for Windows ARM64. This results in an empty `@pypi` repository, causing build failures for projects like TensorFlow that rely on these dependencies. The issue appears to stem from `pip_parse` not correctly identifying or mapping the `windows_aarch64` platform.

Several documentation files are missing required 'includes' links, causing build warnings in the latest docs-as-code main branch. These errors require domain knowledge to resolve and need to be fixed by relevant stakeholders before the next release.

This issue reports an excessive number of warnings generated by the coverage wheel when certain toolchains are not present. The warnings indicate that the bundled coverage tool for rules_python lacks a wheel for a specific Python version and platform, leading to empty lcov files for py_test targets. The user suggests either pinning the Python version or manually configuring the coverage tool.

This feature request aims to enhance the `pip_parse` Bazel rule by adding a new attribute, such as `extra_files`, to allow users to pass additional files like SSL certificates or pip configuration files. This would provide a more integrated Bazel-native approach compared to using environment variables.

This feature request aims to extend the `pip.dep` functionality in `rules_python` to support concrete dependency management directly within `MODULE.bazel` files. Currently, `pip.dep` is only used for abstract dependencies, requiring concrete versions to be specified via `pip.parse` and `requirements.txt`. The proposed solution would allow users to define all dependency version requirements solely within `MODULE.bazel`, similar to the `crate_universe` feature in `rules_rust`.

This issue proposes replacing the use of `rules_oci` with `rules_img` in the project. The motivation is that `rules_img` offers better optimizations. The proposed solution involves adding an example demonstrating `rules_img` and updating the relevant documentation.

A user is experiencing an `AttributeError: module 'sys' has no attribute '_base_executable'` when running a basic `py_binary` and `py_library` example after upgrading from rules_python version 1.9 to 2.0. This issue appears to be a regression and has been observed on both Windows and Debian operating systems.