… except for the part where the dependency definition doesn’t follow the latest approved PEP, and the default constraint with ^ add an upper limit that causes problems.
The thing is, things are working reasonably well right now, so updating to be in sync with the latest PEP isn’t super impactful, whereas switching from requirements.txt -> poetry and pyproject.toml was a big change. So we’ll probably switch eventually, but since we have over a dozen repos and several teams across timezones, it isn’t a priority.
I don’t know what the solution is but like 50% of everything on github that’s in python is broken from dependencies and of those, half of them are fixable if you put a substantial amount of effort into it. It sucks. I’ve spent 2 entire days trying to get any AI tts to work and have gotten nowhere. I’ve tried 'em all, just about. None of them work on Debian.
(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.txt so the next person can just pip install -r requirements.txt instead of figuring out the requirements
either edit requirements.txt manually to do updates, or pip freeze again 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.
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?
Haven’t tried Rye but I have used
uv(which Rye uses to replace pip). Pip install time went down from 58s to 7s. Yes really. Python is fucking slow!Check “uv”. Builds on top, is coming good.
I tried it a little - being able to run
rye syncand not even having to worry about Python versioning is sooooo nice.… except for the part where the dependency definition doesn’t follow the latest approved PEP, and the default constraint with ^ add an upper limit that causes problems.
I moved to PDM.
Eh, by the time I get everyone on board and convert all of our repos, poetry will probably have support for the latest PEP.
Given the glacial pace I’ve been seeing, I would’t be so sure… But understandable if you have many repos and need to reach consensus.
You can reduce some impacts adding explicit >= constraints instead of ^.
The thing is, things are working reasonably well right now, so updating to be in sync with the latest PEP isn’t super impactful, whereas switching from requirements.txt -> poetry and pyproject.toml was a big change. So we’ll probably switch eventually, but since we have over a dozen repos and several teams across timezones, it isn’t a priority.
I’ll certainly take a look though.
I don’t know what the solution is but like 50% of everything on github that’s in python is broken from dependencies and of those, half of them are fixable if you put a substantial amount of effort into it. It sucks. I’ve spent 2 entire days trying to get any AI tts to work and have gotten nowhere. I’ve tried 'em all, just about. None of them work on Debian.
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:
pip freeze > requirements.txtso the next person can justpip install -r requirements.txtinstead of figuring out the requirementsrequirements.txtmanually to do updates, orpip freezeagain laterThere are some issues with this:
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:
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.
Good to know, thank you for educating me!