pip_parse does not generate @pypi packages for Windows ARM64

[MGN-GIT]

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:

external/pypi/requirements_with_markers.out.json

contains platform mappings such as:

[
  "linux_aarch64",
  "linux_arm",
  "linux_ppc",
  "linux_riscv64",
  "linux_s390x",
  "linux_x86_64",
  "osx_aarch64",
  "osx_x86_64",
  "windows_x86_64"
]

but it does not include:

windows_aarch64
windows_arm64
cp313_windows_aarch64

So Windows x64 works, but Windows ARM64 does not.

Things I tried

I patched the pip_parse call to include:

target_platforms = [
    "{os}_{arch}",
    "windows_aarch64",
]

but the generated requirements_with_markers.out.json still only listed windows_x86_64, not windows_aarch64, and requirements.bzl was still empty.

I also tried using the legacy-looking attribute:

experimental_target_platforms = [
    "windows_aarch64",
]

and planned to try:

experimental_target_platforms = [
    "cp313_windows_aarch64",
]

and:

experimental_target_platforms = [
    "all",
]

but I’m not sure what the supported platform string should be for Windows ARM64 in legacy pip_parse.

Expected behavior

pip_parse should support Windows ARM64 / aarch64-pc-windows-msvc and generate non-empty @pypi repositories when requirements contain packages compatible with Windows ARM64.

At minimum, the generated platform marker evaluation should include the appropriate Windows ARM64 platform name, probably one of:

windows_aarch64
cp313_windows_aarch64

Questions

1. What is the correct platform string for Windows ARM64 in pip_parse?
2. Does legacy WORKSPACE pip_parse support Windows ARM64 target platforms?
3. Should target_platforms or experimental_target_platforms be used for WORKSPACE pip_parse?
4. Is win_arm64 wheel tag mapped to windows_aarch64 anywhere in rules_python?
5. Is this expected to work with RULES_PYTHON_ENABLE_PIPSTAR=0?

Reproduction context

This is from TensorFlow’s hermetic Python setup through rules_ml_toolchain:

pip_parse(
    name = "pypi",
    annotations = numpy_annotations,
    python_interpreter_target = "@{}_host//:python".format(
        get_toolchain_name_per_python_version("python"),
    ),
    extra_hub_aliases = {
        "numpy": ["numpy_headers"],
    },
    envsubst = ["RULES_PYTHON_ENABLE_PIPSTAR"],
    requirements_lock = REQUIREMENTS_WITH_LOCAL_WHEELS,
    extra_pip_args = extra_pip_args,
    download_only = is_download_only,
)

The hermetic Python repository is correctly selecting:

python_3_13_aarch64-pc-windows-msvc

[aignas]

For bzlmod there are APIs to configure this out of the box. The code in pip_parse rule is keeping backwards compatibility to previous rules_python versions. If you wish arm64 support, either please migrate to bzlmod or consider submitting PRs for this feature.

[MGN-GIT]

Hi @aignas
I was able to fix this issue by some workarounds. I have one doubt. is there any way to add platform markers in requirements_lock.txt? Lets say I want to install a specific version of wheel for a platform, how can I add a platform marker?

[MugundanMCW]

Any words on this @aignas ?

[aignas]

I am not going to work on this myself as:

• I am working as a volunteer here and I personally am not using Windows myself, so cannot test this.
• I am not working on any WORKSPACE projects and with it's removal soon I find other more important things to work on.

@MugundanMCW, @MGN-GIT, since this is an open source project, and we are happy to accept contributions, feel free to create a PR that would meet our contribution guidelines. The code itself should be documented enough to get around with some AI help.

[MugundanMCW]

Yeah sure @aignas