Curious what others have to say, but my go to is to have a requirements.in with direct packages I need for the project, and then run pip-compile to 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 in setup.py
I 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?
Well if the requirements.txt is pinned to a specific version of a dependency of a dependency, you might not know or really care why that’s set. But then this becomes a nightmare and dependency hell laterif you want a newer version of some package, and that newer version requires a bunch of newer packages and loses the others. At that point you probably will toss your old file and start a new one from scratch piecing together all the requirements with like pip freeze in a new virtual environment.
Sure you could omit the versions, but then everytime you deploy, you don’t know what you’re going to get and a deployment today would be very different next week with a whole bunch of different versions of dependencies.
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.
Why not put all dependencies and all with versions. I do that
Well if the
requirements.txtis pinned to a specific version of a dependency of a dependency, you might not know or really care why that’s set. But then this becomes a nightmare and dependency hell laterif you want a newer version of some package, and that newer version requires a bunch of newer packages and loses the others. At that point you probably will toss your old file and start a new one from scratch piecing together all the requirements with likepip freezein a new virtual environment.Sure you could omit the versions, but then everytime you deploy, you don’t know what you’re going to get and a deployment today would be very different next week with a whole bunch of different versions of dependencies.