Provide centrally pinned Python CLI tools through uv without requiring a container or Bazel

Aberta
  • Algo errado?
#189 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python, shell
Domínio
build-system, developer-experience, tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Shell
Estrelas
5
Forks
10
Merge médio
23h 5min
PRs com merge (30d)
29

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

  • Sem Dockerfile nem arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de eclipse-score/devcontainer

Todas as issues de eclipse-score/devcontainer

Issues semelhantes

Mais issues de Shell/Bash

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.