bazel-contrib / bazel-contrib/rules_python

pip_parse does not generate @pypi packages for Windows ARM64

Open
#3,913 5 comments 0 reactions 0 assignees View on GitHub
help wanted P4 type: pip
Dominant language
Starlark
Stars
688
Forks
721
Avg merge
15h 7m
Merged PRs (30d)
76

Description

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

```starlark
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:

```text
external/pypi/requirements.bzl
```

contains no packages:

```starlark
all_requirements = []
all_whl_requirements_by_package = {}
all_data_requirements = []
_packages = []
```

This causes Bazel analysis failures later for normal TensorFlow deps such as:

```text
@pypi//wheel
@pypi//gast
```

because the `@pypi` repo is empty.

The generated marker file:

```text
external/pypi/requirements_with_markers.out.json
```

contains platform mappings such as:

```json
[
"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:

```text
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:

```starlark
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:

```starlark
experimental_target_platforms = [
"windows_aarch64",
]
```

and planned to try:

```starlark
experimental_target_platforms = [
"cp313_windows_aarch64",
]
```

and:

```starlark
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:

```text
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`:

```starlark
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:

```text
python_3_13_aarch64-pc-windows-msvc
```

Contributor guide

Open the contributing guide

Research direction

Start in @rules_python//python:pip.bzl at the legacy pip_parse implementation, then inspect how it produces external/pypi/requirements_with_markers.out.json and external/pypi/requirements.bzl. Trace the platform-name and wheel-tag mapping for Windows ARM64 and compare the target_platforms and experimental_target_platforms paths; done means supported configuration generates the expected Windows ARM64 platform entry and non-empty package repositories.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.