bazel-contrib / bazel-contrib/rules_python
pip_parse does not generate @pypi packages for Windows ARM64
- 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
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