chore(flagd): protobuf modules are only generated by a build
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ó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 68/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- build-system, ci-cd, testing
Hướng nghiên cứu
Start by comparing the flagd provider setup with the flagd testkit's hatch_build_sync.py and the poe test flow. Trace how protoc generation currently depends on the hatch-protobuf build hook, then update the provider's test and build configuration and CONTRIBUTING.md to use the uv-era workflow. Done means tests generate importable protobuf modules before running, builds package the generated output, and the documented commands work without hatch.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The flagd provider's protobuf modules are generated only by the hatch-protobuf build hook, so nothing importable exists until a distribution is built.
Two consequences:
- CI runs
uv buildfor every package on every Python version, purely so this one package gets its generated modules. CONTRIBUTING.mdstill tells contributors to runhatch buildonce and to test withhatch test. Both predate the move to uv, andhatchis not a dependency of the repo any more, so following the instructions fails.
Generating code is a test input, not an artifact of the build (pypa/hatch#1824). The flagd testkit already handles this correctly: hatch_build_sync.py is an ordinary script, poe test runs it first, and the build hook only ships what it produced. The flagd provider should do the same for protoc.
- Ngôn ngữ chính
- Python
- Star
- 27
- Fork
- 33
- Merge trung bình
- 11 giờ 10 phút
- Pull request đã merge (30 ngày)
- 14
Chuẩn bị môi trường
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 open-feature/python-sdk-contrib
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
open-feature/python-sdk-contrib#439 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
UnleashProvider.track has the wrong signature: client.track raises TypeError instead of no-opĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
open-feature/python-sdk-contrib#433 ·
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
open-feature/python-sdk-contrib#421 ·
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 90/100
open-feature/python-sdk-contrib#417 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Needs Triage question
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
open-feature/python-sdk-contrib#420 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của open-feature/python-sdk-contrib
Issue tương tự
-
ACK_WAITING HELP_WANTED UPDATE_CS
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
OWASP/CheatSheetSeries#2458 ·
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 82/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 90/100
BasedHardware/omi#19711 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Qwen3_5MoeModel no longer returns router_logits, breaking aux loss with output_router_logits=TrueĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
huggingface/transformers#49172 ·
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 82/100
vllm-project/vllm-metal#885 ·
Maintainer thường phản hồi trong vòng 1 ngày