Support for the uv package manager (uv.lock)
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 52/100
- Tipo de issue
- Funcionalidade
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Stack de tecnologia
- python
- Domínio
- build-system
Direção de pesquisa
Comece rastreando o suporte existente a Pipfile/Pipfile.lock e seu fluxo de geração de requirements.txt; em seguida, compare esse caminho com uv export e com o fluxo normal de pip install. Considera-se concluído quando projetos que contêm uv.lock e pyproject.toml puderem ser enviados sem um requirements.txt mantido manualmente, com os fallbacks indicados para a versão do Python e o instalador cobertos.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Hi,
I couldn't find any existing or past issues mentioning this.
It'd be great to support uv for dependency management. It's one of the most widely used Python package managers, and a lot of projects now standardise on uv.lock the way they used to on Pipfile.lock. A good number of our projects at SAP have moved over to uv + uv.lock entirely, and today those apps can't be pushed as-is -- you end up keeping a separate requirements.txt in the repo by hand, purely for compatibility with the CF Python buildpack, which rather defeats the point of having a lockfile.
The nice part is the buildpack already has the right shape for this. pipenv support works by generating a requirements.txt (from Pipfile.lock) and then handing off to the normal pip install path -- uv fits that exact pattern, and uv export exists for precisely this purpose.
Rough idea I'm thinking of would be:
- Detect
uv.lock(+pyproject.toml), much likePipfileis detected today - Run
uv export --format requirements-txtto turn the lock into arequirements.txt - Install it with
uv pip install(uv's installer is dramatically faster than pip), falling back to pip - Read the Python version from
.python-version/requires-pythoninpyproject.toml
Routing through a generated requirements.txt keeps all the existing machinery working unchanged, so it should be a reasonably contained change. plus uv ships as a PyPI wheel, so it can be added as a manifest dependency the same way pipenv is.
I'd be happy to put together a PR if this seems worth including.
Thanks!
- Linguagem predominante
- Go
- Estrelas
- 122
- Forks
- 281
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de cloudfoundry/python-buildpack
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 35/100
cloudfoundry/python-buildpack#989 · 4 comentários ·
-
Dependency Deprecation AlertTalvez já em andamento @brayanhenao assumiu há 1188 dias. Abertadependency-deprecation
cloudfoundry/python-buildpack#784 · 36 comentários · 1 responsável ·
Todas as issues de cloudfoundry/python-buildpack
Issues semelhantes
-
bug needs triage
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
netdata/netdata#24062 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
meshery/meshery#22119 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
automation documentation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
Mantenedores costumam responder em até 1 dia