pip.parse ignores uv.lock dependency-edge platform markers
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- backend, build-system
Hướng nghiên cứu
Read _parse_uv_lock_json in python/private/pypi/parse_requirements.bzl and inspect PR #4286, which already proposes a fix and includes regression coverage. The reproduction in this issue shows the failure for uvloop across Linux x86_64 and macOS arm64; done means only the Linux artifact is selected and the related parser and uv-lock conversion tests pass.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Affected Rule
pip.parse(uv_lock = ...), specifically _parse_uv_lock_json in python/private/pypi/parse_requirements.bzl.
Is this a regression?
Unknown. Confirmed against upstream main at 9f3ab0630537ce54356d78a28f4618d926ec31ce.
Description
When importing a universal uv.lock, packages with platform-specific dependency edges are assigned to platforms on which they are unreachable. The parser checks package-level resolution-markers but ignores the marker on dependency edges. uv does not necessarily write package-level markers for these dependencies.
For a Linux-only uvloop dependency, the parser selects a Linux wheel for Linux and its source archive for macOS. If a package has a compatible macOS wheel, that artifact can also be selected even though the package should be absent on macOS.
Minimal reproduction
Create this pyproject.toml:
[project]
name = "rules-python-platform-marker-repro"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["uvloop==0.22.1; sys_platform == 'linux'"]
[tool.uv]
environments = [
"sys_platform == 'linux' and platform_machine == 'x86_64'",
"sys_platform == 'darwin' and platform_machine == 'arm64'",
]
Generate uv.lock with uv lock. The lock generated by uv 0.11.21 contains:
[[package]]
name = "rules-python-platform-marker-repro"
version = "0.1.0"
source = { virtual = "." }
dependencies = [
{ name = "uvloop", marker = "platform_machine == 'x86_64' and sys_platform == 'linux'" },
]
The uvloop package entry has Linux wheels and an sdist, but no package-level resolution-markers. The lock's top-level resolution markers are separate from package-level markers.
Importing this lock with pip.parse for target_platforms = ["linux_x86_64", "osx_aarch64"] should resolve uvloop only for Linux. To confirm the failure independently of package installation, I invoked the unmodified public parse_requirements function through an isolated Bazel module against a JSON serialization of this actual lock, with Python 3.9 Linux x86_64 and macOS arm64 platform definitions. The parser returned:
uvloop-0.22.1-cp39-cp39-manylinux2014_x86_64.manylinux_2_17_x86_64.manylinux_2_28_x86_64.whl: ["linux_x86_64"]
uvloop-0.22.1.tar.gz: ["osx_aarch64"]
Expected: Only the Linux wheel; no macOS artifact.
Actual: The parser additionally selects uvloop's sdist for macOS. No macOS package build or installation was attempted in this reproduction; the incorrect artifact selection itself was observed directly.
Environment
- Host: macOS arm64.
- Target marker environments: Linux x86_64 and macOS arm64, Python 3.9.6.
- Bazel: 9.1.1.
- uv: 0.11.21.
- rules_python: upstream commit
9f3ab0630537ce54356d78a28f4618d926ec31ce.
Proposed fix
PR #4286 walks the dependency graph from virtual/editable workspace roots per target platform, applying edge markers and retaining packages only on platforms where they are reachable. It also preserves package resolution markers and version/source identities and follows requested dependency extras.
The same real-lock reproduction selects only the Linux artifact with that patch. The PR includes regression coverage for this case and related graph/extras cases; all 66 selected parser and uv-lock conversion tests pass locally.
- Ngôn ngữ chính
- Starlark
- Star
- 688
- Fork
- 728
- Merge trung bình
- 1 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 94
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của bazel-contrib/rules_python
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
bazel-contrib/rules_python#4251 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
bazel-contrib/rules_python#4164 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
go:embed stdlib_list.txt file in gazelle/python/std_modules.go is missingCó thể đã có người làm @udaya2899 đã nhận 22 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
bazel-contrib/rules_python#3821 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
bazel-contrib/rules_python#4278 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
bazel-contrib/rules_python#4269 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của bazel-contrib/rules_python
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 87/100
huggingface/smolagents#3045 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
router-for-me/CLIProxyAPI#6851 ·
Maintainer thường phản hồi trong vòng 1 ngày