. ├── common_lib # Biblioteca Python compartilhada ├── services │ ├── a_service │ │ ├── pyproject.toml │ │ └── uv.lock │ ├── b_service │ │ ├── pyproject.toml │ │ └── uv.lock │ ├── c_service │ │ ├── pyproject.toml │ │ └── uv.lock ├── pyproject.toml └── uv.lock
Você tem uma biblioteca compartilhada (common_lib) e vários serviços, cada um com seu próprio pyproject.toml e uv.lock. Há também um pyproject.toml e uv.lock na raiz. Suas metas incluem:
Dependências compartilhadas (como FastAPI) gerenciadas de forma eficiente.
Dependências exclusivas por serviço, mantendo isolamento.
Configurações compartilhadas para ferramentas como ruff e pre-commit.
Suporte a imagens Docker menores e rebuilds independentes.
Resposta: Sim, ter um uv.lock separado para cada serviço é uma abordagem válida e, na maioria dos casos, recomendada para o seu cenário. Aqui está o porquê:
Isolamento de Dependências: Cada serviço com seu próprio uv.lock garante que as dependências sejam resolvidas independentemente. Isso evita conflitos de versões entre serviços (por exemplo, se a_service precisa de fastapi==0.115.0 e b_service precisa de fastapi==0.120.0).
Imagens Docker Menores: Com uv.lock por serviço, você pode instalar apenas as dependências necessárias para cada serviço em sua imagem Docker, reduzindo o tamanho da imagem e o tempo de build.
Builds Independentes: Se um serviço altera suas dependências, apenas o uv.lock desse serviço precisa ser atualizado, e apenas a imagem Docker correspondente precisa ser reconstruÃda. Isso é crucial para pipelines CI/CD eficientes.
Prevenção de Vazamento de Dependências: Ambientes virtuais isolados por serviço, gerenciados pelo uv, evitam que dependências de um serviço "vazem" para outro, mantendo a modularidade.
Prática Alinhada com Microsserviços: Em arquiteturas de microsserviços, o isolamento é um princÃpio fundamental. Gerenciar dependências separadamente com uv.lock por serviço alinha-se com essa filosofia.