Hacker News Reader

Comment by espdev | Hacker News Reader

> Just a few months back I said I would never use uv. I was already used to venv and pip. No need for another tool I thought

Really? :)

requirements.txt is just hell and torture. If you've ever used modern project/dependency management tools like uv, Poetry, PDM, you'll never go back to pip+requirements.txt. It's crazy and a mess.

uv is super fast and a great tool, but still has roughnesses and bugs.

View on HN

Pip-tools+requirements.txt helped me survive the past few years. I also never thought I needed uv, but after all the talk about it I gave it a spin and never want back. It’s just so blazing fast en convenient.

We use uv to compile requirements.txt from pyproject.toml to get the locked versions.

    # Makefile
    compile-deps:
     uv pip compile pyproject.toml -o requirements.txt
    
    compile-deps-dev:
     uv pip compile --extra=dev pyproject.toml -o requirements.dev.txt

What for? Support legacy CI/CD pipelines or something like that? uv.lock already contains locked versions of all dependencies plus a lot of other needed metadata.

> What for? Support legacy CI/CD pipelines

Yes. Azure, for instance, looks for requirements.txt if you deploy a web app to Azure App Service.

If you’re doing a code-based deployment, it works really well. Push to GitHub, it deploys.

You can of course do a container-based deployment to Azure App Service and I’d assume that will work with uv.

"legacy CI/CD pipelines"

Damn I'm getting old

Maybe. I've been programming in C++ and also in Python for almost 20 years. And I'm just happy that Python has finally started to have convenient tools for packaging and dependency management. I thought everything was cursed here, and I just hate requirements.txt. It seems they were able to overcome this curse.

pip also works with pyproject.toml. Sticking with requirements.txt is a self-imposed constraint.

Reply on news.ycombinator.com