Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Generate target_compatible_with for whl_library_targets

Abierto
  • ¿Algo no está bien?
#3,686 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
build-system

Línea de trabajo

Empieza en python/private/pypi/whl_library_targets.bzl e inspecciona la utilidad parse_whl_name mencionada en el issue, siguiendo cómo los nombres de archivo de los wheels llegan a los targets py_library generados. Se considera terminado cuando las etiquetas de wheel específicas de la plataforma producen la restricción target_compatible_with correspondiente, mientras que los wheels pure-Python permanecen sin restricciones; verifica los targets de Bazel generados y el comportamiento de build relevante.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

🚀 feature request

Relevant Rules

whl_library_targets macro in python/private/pypi/whl_library_targets.bzl

Description

When rules_python generates BUILD targets for platform-specific wheels (e.g., torch-2.8.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl), the resulting py_library does not set target_compatible_with. This means Bazel cannot distinguish platform-specific wheels from pure-Python ones at analysis time.

We maintain a repo that targets both x86_64 and aarch64. Our pyproject.toml uses PEP 508 environment markers to restrict certain dependencies to x86_64:

dependencies = [
    "torch==2.8.0; platform_machine == 'x86_64'",
    "opencv-python==4.11.0.86; platform_machine == 'x86_64'",
    "tensorboard==2.20.0; platform_machine == 'x86_64'",
    # ... many more x86_64-only deps
]

We generate separate lock files per platform via uv pip compile. The pip.parse extension correctly fetches platform-specific wheels. However, the generated py_library targets for these wheels have no target_compatible_with constraint.

This causes two issues:

  1. bazel build //... fails on aarch64: Bazel attempts to build targets that transitively depend on x86_64-only wheels, which fail because the wheel files don't exist for aarch64. With target_compatible_with, Bazel would instead skip incompatible targets (printing SKIPPED in the build output).

  2. Manual target_compatible_with annotations required everywhere: As a workaround, we must add target_compatible_with = ["@platforms//cpu:x86_64"] to every py_test and py_binary that transitively depends on an x86_64-only wheel. This is error-prone and tedious — our repo currently has dozens of such annotations scattered across BUILD files.

Describe the solution you'd like

The whl_library_targets macro should automatically infer target_compatible_with from the wheel filename's platform tag and set it on the generated py_library.

Wheel filenames follow a well-defined format (PEP 427): {distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl. The platform tag encodes the target architecture:

Platform tag suffix Constraint
_x86_64, _amd64 @platforms//cpu:x86_64
_aarch64, _arm64 @platforms//cpu:aarch64
_i686 @platforms//cpu:x86_32
_ppc64le @platforms//cpu:ppc
_s390x @platforms//cpu:s390x
any (pure-Python) (no constraint)

A possible implementation in whl_library_targets.bzl:

load(":parse_whl_name.bzl", "parse_whl_name")

_PLATFORM_TAG_CPU_MAP = {
    "x86_64": "@platforms//cpu:x86_64",
    "amd64": "@platforms//cpu:x86_64",
    "aarch64": "@platforms//cpu:aarch64",
    "arm64": "@platforms//cpu:aarch64",
    "i686": "@platforms//cpu:x86_32",
    "ppc64le": "@platforms//cpu:ppc",
    "s390x": "@platforms//cpu:s390x",
}

def _target_compatible_with_from_whl_name(whl_filename):
    if not whl_filename or not whl_filename.endswith(".whl"):
        return []
    parsed = parse_whl_name(whl_filename)
    if parsed.platform_tag == "any":
        return []
    for suffix, constraint in _PLATFORM_TAG_CPU_MAP.items():
        if parsed.platform_tag.endswith("_" + suffix):
            return [constraint]
    return []

Then in the whl_library_targets function, pass it to py_library:

rules.py_library(
    ...
    target_compatible_with = _target_compatible_with_from_whl_name(name),
    ...
)

This leverages the existing parse_whl_name utility already available in rules_python.

Describe alternatives you've considered

  1. Manual target_compatible_with on downstream targets: This is what we currently do — every py_test/py_binary that transitively depends on an x86_64-only wheel gets a manual target_compatible_with = ["@platforms//cpu:x86_64"]. This is tedious, error-prone, and doesn't scale. Each new test file requires the developer to figure out whether any transitive dependency is platform-specific.

  2. Patching rules_python locally via single_version_override: We currently apply a local patch to whl_library_targets.bzl (via single_version_override in MODULE.bazel) that implements the solution described above. This works but is a maintenance burden — we have to keep the patch in sync with upstream rules_python updates.

  3. Using pip.parse whl_modifications to post-hoc add target_compatible_with: This would require listing every platform-specific wheel individually and is even more error-prone than option 1.

The information to infer target_compatible_with is already embedded in the wheel filename. Having rules_python set it automatically would eliminate all three workarounds and make cross-platform Bazel builds work correctly out of the box.

Lenguaje dominante
Starlark
Estrellas
688
Forks
723
Merge medio
1 d 20 h
PR fusionados (30 d)
45

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de bazel-contrib/rules_python

Todos los issues de bazel-contrib/rules_python

Issues similares

Más issues de Build System

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.