[frou_dh]

Look at what the well-regarded pip-tools (https://github.com/jazzband/pip-tools) does, for a disciplined approach to these requirements files. You don't necessarily need to adopt that tool, but can maybe take inspiration from it.

[robinweiss]

Thanks! I personally use those tools, but a lot of times it's hard to convince people to switch from their hand-written requirements.txt. I was looking for some bullet-proof arguments to end that discussion once and for all :D

[mlegendre]

"Reproducible environments" sounds like a strong argument to me. If you don't have a reproducible environment, you have no guarantee that your code will work at any point in time. The more complex the projet and its dependencies, the more likely breakage will happen with a new version of a dependency.

Maybe this is something that is best learnt the hard way? Something you understand once you reflect back on how many hours you have lost fighting with dependencies, instead of doing what you actually wanted to do with the code (be it running it, developping, debugging, bisecting...).

Freezing dependencies comes at a cost though, especially since dependency management in python is a PITA. So this is a trade-off. For simpler, projects or scripts, I personally don't bother with freezing dependencies, and I handle issues when they happen. (And they do happen.)

[mattbillenstein]

I use pip-compile in my flows - it's the best of both worlds, you get your declared direct dependencies via requirements.in, and the full blown locked dependencies then in requirements.txt. It's my preferred way to manage this now.

[frou_dh]

And a key thing is that both files can be committed to source control, not just one or the other.

[mattbillenstein]

Yeah, and the other bits about pip-compile -P to upgrade a single package and whatnot are very handy.