this post was submitted on 01 Aug 2026
121 points (99.2% liked)
Programmer Humor
43838 readers
102 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 7 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's right, you shouldn't be using requirements.txt in 2026
What should I use instead? pyproject.toml?
I am pretty new to Python so I'm not very familiar with the ecosystem yet...
Curious what others have to say, but my go to is to have a
requirements.inwith direct packages I need for the project, and then runpip-compileto generate all the dependencies with their exact version at the time so that deployments are repeatable. This works well for deployment, but if I were writing a library for others to use, I think you put the direct dependencies insetup.pyI don't quite understand that. I did some research, and I read that the requirements.txt is somehow generated from requirements.in. But what is the difference between the two files then? Could you give me an example of what a requirements.in file would look like?
Thank you!
Please use a pyproject.toml file for both project setup and dependency management. It actually is standardized now in PEPs.
uv is a great tool, now comes with a build tool as well. It has become a de-facto standard.
Ohhh now I get it. It's basically like
package.jsonandpackage-lock.jsonin node, but for Python.It's a bit strange to me that this isn't the default in Python...
Yes exactly, like if I know my app needs the requests library, I will just put that in
requirements.inbut after compilerequirements.txtwill include the exact version of requests and every version of each dependency. So that every time pip install is run, all dependencies are always the same despite what happens upstream