You must log in or register to comment.
Having more than one obvious way is unpythonic
Unfortunately, pip, the obvious way, kind of sucks. So I use poetry, which seems to work nicely.
I’m using Poetry as well. But I really hope Rye works out so we can finally end this madness.
Interesting. I just learned about Rye today. Has anybody tried it? Does it live up to the promise?
I tried it a little - being able to run
rye syncand not even having to worry about Python versioning is sooooo nice.
Wait, what’s wrong with pip?
(Disclaimer: I grade my Python proficiency slightly above beginner. I used it for some research in college and grad school, and I’ve made a few helpful scripts at work, but I am not anything approaching an expert)
It does its job well, but it doesn’t do much more than that.
The main workflow w/ Pip is:
- install whatever you need to get your app working
pip freeze > requirements.txtso the next person can justpip install -r requirements.txtinstead of figuring out the requirements- either edit
requirements.txtmanually to do updates, orpip freezeagain later
There are some issues with this:
- dependencies that are no longer needed tend to stick around since they’re in the requirements.txt
- updating dependencies is a manual process and pretty annoying, especially when different packages have different dependencies
- requirements.txt doesn’t have any structure, so to do something like separating dev vs prod dependencies, you need two (or more) requirements.txt files
It’s totally fine for one-off scripts and whatnot, but it gets pretty annoying when working across multiple repositories on a larger project (i.e. what I do at work with microservices).
Poetry improves this in a few ways:
- poetry.lock - similar to requirements.txt, in that it locks all dependencies to specific versions
- pyproject.toml - lists only your direct dependencies and certain exceptions (i.e. if you want to force a specific dependency version)
- package groups - we tend to have local (linters and whatnot), test (deps for unit tests), and the default group (prod deps), so you can install only what you need (e.g. our CI uses test, prod uses no groups, and local uses everything)
There’s a simple command to update all dependencies, and another command to try to add a dependency with minimal impact. It makes doing package updates a lot nicer, and I can easily compare direct dependencies between repositories since there’s minimal noise in the pyproject.toml (great when doing bulk updates of some critical dependency).
TL;DR - pip is fine for small projects, alternatives are nice when dealing with large, complex projects because it gives you nicer control over dependencies.
By the creator of Flask and many other things
and Conda takes 20 minutes to do anything these days… 😂 send help
… and every one of them destroys single source of truth for installed state. Most of them have no validation potential, and most of them are imperfect upgrades/downgrades.
If you don’t know why all that’s important, just remember why fired all our mentor types 20 years ago after the Y2K bust and so you had noone to teach you why. Mistakes like lennart’s Cancer didn’t grow in the light of rich knowledge sharing.
I’ve tried several and all of them left be disappointed eventually.
I landed on hatch. The way it handles venvs and python versioning is awesome, and can also use UV. I haven’t used UV yet tho.
This article is an excellent update on the state of Python package management tools.
I agree, although it undersells hatch and has a title that made me roll my eyes. Very well researched, none of the usual hot takes and clichés.
Pip-tools!
You can use uv now and have Rust speeds for the same functionality.
