Add opt-in strict resolution of explicit `main` labels in `py_binary` and `py_test`
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- build-system
Hướng nghiên cứu
Read python/private/py_executable.bzl, especially determine_main in the version linked by the issue, and trace how py_binary and py_test pass main and srcs into entrypoint selection. Implementing this needs analysis-time artifact comparison, validation, and compatibility with generated outputs and aliases. Done means strict mode is opt-in, rejects mismatched artifacts with a clear diagnostic, preserves default behavior, and has coverage for the listed cases.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Relevant Rules
py_binary and py_test.
Description
The main attribute is label-valued, but entrypoint selection uses only ctx.attr.main.label.name to suffix-match files in srcs. Consequently, the explicit label does not necessarily identify the file selected as the entrypoint.
For example, suppose shared/entry.py exists and is exported by //shared, while app/entry.py does not exist:
# app/BUILD.bazel
load("@rules_python//python:defs.bzl", "py_binary")
py_binary(
name = "app",
srcs = ["//shared:entry.py"],
main = "entry.py",
)
Bazel resolves main to //app:entry.py, but the rule selects //shared:entry.py through filename matching. The query graph can nevertheless contain a source-file target for the nonexistent //app:entry.py. Tools that consume this graph and inspect source files, such as bazel-diff, can then report missing-file warnings even though the actual entrypoint is correctly supplied through srcs.
There is also an ambiguity case:
py_binary(
name = "app",
srcs = [
"//foo:entry.py",
"//bar:entry.py",
],
main = "//foo:entry.py",
)
Filename matching finds two candidates even though the explicit label identifies one file unambiguously.
In 2.4.3, the latest stable release, determine_main retains this filename-matching behavior. I recognize that it is intentional; this request is for an optional stricter contract, not an incompatible change to the default.
Describe the solution you'd like
Add an opt-in strict mode, for example a strict_main attribute defaulting to False. The specific API is open to discussion; enabling it through project-owned wrappers would allow gradual adoption.
When strict mode is enabled and main is explicitly provided:
- Resolve the full label to its file artifact and use that artifact as the entrypoint.
- Require that artifact to be among the files supplied by
srcs. - Fail during analysis with a clear diagnostic if the requirement is not satisfied, rather than selecting a different file with a matching name.
- Compare resolved artifacts rather than label strings, preserving support for aliases, single-file filegroups, and generated sources.
- Preserve applicable entrypoint file-type validation.
Validation should compare the resolved main and srcs artifacts during analysis, including declared generated outputs. Bazel's normal build-time input and output checks should remain responsible for enforcing file availability. For example, a generated entrypoint is valid when both attributes resolve to the same declared output artifact; its generating action need not have run yet.
When main is omitted, retain the existing default-entrypoint inference. When strict mode is disabled, preserve existing behavior.
This would let projects enforce that explicit entrypoint labels accurately describe their dependencies without requiring an immediate migration for all users.
Describe alternatives you've considered
Correct individual declarations. Using main = "//shared:entry.py" fixes the first example's misleading graph entry. This is a useful immediate workaround, but the rule still accepts future mismatches, and fully qualified labels do not resolve the second example's filename ambiguity.
Project-local linting or analysis checks. These could enforce the policy locally, but would require separate tooling to validate the relationship between the resolved main and srcs artifacts. Enforcing the contract in the executable rule would provide a direct diagnostic where the entrypoint is selected.
Make exact label resolution the default immediately. This would be a breaking change for configurations that rely on the documented filename-matching behavior. An opt-in mode provides a compatibility-preserving adoption path.
- Ngôn ngữ chính
- Starlark
- Star
- 688
- Fork
- 728
- Merge trung bình
- 17 giờ 24 phút
- Pull request đã merge (30 ngày)
- 131
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
-
Broken links in the docsĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
bazel-contrib/rules_python#4319 ·
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 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
-
need: repro
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
bazel-contrib/rules_python#4315 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
pip.parse ignores uv.lock dependency-edge platform markersCó thể đã có người làm @kdelalic đã nhận 6 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 20/100
bazel-contrib/rules_python#4287 ·
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 65/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 1 ngày
-
area:install bug needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Wheels for Python 3.15Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
mongodb/winkerberos#175 ·