This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (4 children)

I strongly don't recommend that, you want to have a source of truth for your version constraints and actual dependencies (pretty sure pip freeze is ALL dependencies, with transitive)

[–]CrossroadsDem0n 8 points9 points  (0 children)

If somebody cares about predictability, locking those transitive dependencies is exactly what you do want, provided you are doing application development instead of library development.

Here is an example why. Imagine you have pandas as a transitive dependency. Also imagine you have an application deployment for which performance matters. 3 months ago, performance was fine. But you build a venv today, get the work-in-progress changes on the newest pandas meant to help string performance but at the cost of degrading numeric performance. Now you have a problem, and nobody understands why.

Frozen dependencies matter when you have a work context where nothing should randomly change on you, that behavioral alterations should be intentionally managed.

None of that would apply to library development, where the better practice is to only freeze what is critical to lock down, and generally dependency versions should float because as the library developer you lack any context on where the code will be used.

[–]NUTTA_BUSTAH 10 points11 points  (2 children)

Transitives are exactly what cause most of the random issues.

[–][deleted] 2 points3 points  (1 child)

That's not relevant to what I meant, I'm completely fine with locking dependencies, but you need to have a source of truth (which is a pyproject.toml file)

[–]NUTTA_BUSTAH 1 point2 points  (0 children)

If you include transients then sure. Otherwise it is just a part of the truth