Provide centrally pinned Python CLI tools through uv without requiring a container or Bazel
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 35/100
- Issue 類型
- 功能
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
研究方向
Start by locating the shared tool catalog and tracing how the existing container and Bazel delivery paths consume it. Then assess how a Python package invoked through uv could use those same definitions while preserving the single version authority; done means the uv path works for a pinned DevContainer release and the existing delivery paths remain intact.
由索引模型根據 Issue 內容生成。
描述
Use case
As a repository maintainer, I want local development and CI to use the same centrally maintained tool versions without requiring developers or lightweight CI jobs to run a DevContainer or install Bazel. For example, our shared PR workflow runs pre-commit through uvx pre-commit, while developers use the version installed in the DevContainer. This recently meant that CI used pre-commit 4.7.0 while local checks used 4.5.1, allowing an incompatible hook configuration to pass locally and fail in CI.
I want to select one DevContainer release and run its pre-commit version through uv. I should not have to copy individual tool pins into every consuming repository or maintain another requirements file independently of the existing tool catalog.
Proposed solution
Provide a Python package in this repository that can be run through uvx from a pinned Git release, without requiring publication to PyPI. The package should expose a runner for the Python CLI tools defined in the shared catalog, resolve the selected tool to its centrally pinned package version and entrypoint, and execute it in an isolated uv-managed environment. Consumers supply the DevContainer release reference, tool name, and arguments; uv handles installation and caching. A compatible uv installation is a prerequisite and is not bootstrapped or version-pinned by this runner.
The DevContainer repository must remain the central version authority for all three delivery paths: container, uv, and Bazel. Package the existing catalog with the runner and have every delivery path consume the same tool definitions. Do not introduce separately maintained tool versions in Python package metadata, generated consumer wrappers, or downstream repositories. Existing container and Bazel delivery should continue alongside the new uv path. This initial scope covers Python CLI tools such as pre-commit; it does not require uv delivery for every native tool in the catalog.
- 主要語言
- Shell
- 星號
- 5
- 分支
- 10
- 平均合併
- 23 小時 5 分鐘
- 30 天內合併 PR
- 29
環境準備
在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 沒有貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
eclipse-score/devcontainer 的其他 Issue
-
難度 5/5 一週以上 新手友好度 35/100
eclipse-score/devcontainer#213 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 30/100
eclipse-score/devcontainer#190 ·
維護者通常 1 天內回覆
-
bug: github releases without devcontainer releases可能已有人在做 @vibhoraggarwal 於 40 天前認領。 未關閉bug
難度 3/5 1-2 天 新手友好度 55/100
eclipse-score/devcontainer#162 ·
維護者通常 1 天內回覆
-
Versioning mess未關閉
難度 5/5 一週以上 新手友好度 35/100
eclipse-score/devcontainer#155 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 52/100
eclipse-score/devcontainer#115 · 6 則留言 ·
維護者通常 1 天內回覆
查看 eclipse-score/devcontainer 的全部 Issue
相似的 Issue
-
help wanted new command
難度 2/5 1-3 小時 新手友好度 76/100
tldr-pages/tldr#25111 ·
維護者通常 1 天內回覆
-
bug
難度 1/5 1 小時以內 新手友好度 78/100
fabriziosalmi/secure-proxy-manager#619 ·
維護者通常 1 天內回覆
-
enhancement good first issue
難度 1/5 1 小時以內 新手友好度 98/100
-
難度 2/5 1-3 小時 新手友好度 75/100
-
難度 2/5 1-3 小時 新手友好度 76/100