It's about dependencies of dependencies.

Requirements.txt only lists versions of your project's requirements, but Pip actually automatically installs dependencies of those requirements too. And those versions aren't listed in your requirements.txt.

https://realpython.com/pipenv-guide/#dependency-management-w... -- This page about Pipenv vs pip + virtualenv goes into more detail.

You can just 'pip freeze > requirements.txt'

Boom, all recursive dependencies frozen to their current state.

But you don't want to necessarily freeze them to their current state. Yes for repeatable builds, but not in your list of dependencies. They're different concerns and Pipenv splits them.

Giving a shout out to pip-tools here... it's a great, simple solution for pinning your requirements (including the deps of your deps), and keeping your venv's in sync.

pip freeze gets everything installed.

Yes, that 'freezes' everything installed... but that's the point. If you want to update a direct dependency, you just do pip install -u <my-dep>. Any indirect dependencies are updated, and you freeze again.

Sometimes direct-dependency-a and direct-dependency-b have a conflict on which version of indirect-dependency-y you need. This is what we call doing 'actual work.'

^This. I don't understand everyone in this thread complaining that it's hard to update a direct dependency. You literally just pip install it and "pip freeze > requirements.txt" again.

In my experience, the issues come around when you try to build envs cross-platform. There are a lot of dependencies that have missing versions or bugs for certain platforms. This is not a pip/venv problem though--it is more of a python problem.

It’s easy to also get the versions of all sub dependencies and put them in requirements.txt

That makes updating your direct dependencies harder. If you upgrade to using newer version of something, and that things dependencies have changed, you have to manually figure out which dependencies in requirements.txt were for it, and update or remove those etc.

> It’s easy to also get the versions of all sub dependencies and put them in requirements.txt

Is it easy to automatically do this when you want a new package version, without having to remember to do it? Is it easier to put together this process and train other developers in it and be diligent in its use? Is all of that easier than installing an application that has a similar interface to other tools, that does all that for you, and has a community of people to help with issues?

But then you're suddenly responsible for keeping track of your subdependencies and updating the versions of each that you want. That should be up to the dependencies.

Also if you manage to drop a dependency, you don't have an easy way to remove the things from requirements.txt that are only there because they're a subdependency.

Putting it all in one requirements.txt is just too simplistic.

If I had such need, I guess I could have two versions of the requirements.txt:

- One with direct dependencies (versions pinned) - One with direct dependencies + subdependencies (pip freeze output)

Am I being too naive ? (obviously yes if such tool as pipenv exists, but I'm trying to figure why people need *.lock files).

This is close to what pipenv does.

It also adds dependency management. If one subdependency is library_a > 1.0, and another is library_b < 2.0 while also e.g. 2.1 exists, then it will try to find a version between 1.0 and 2.0. Pip doesn't do that.

So in my mind, that's what pipenv is -- pip, virtualenv, those two files, plus dependency management.

> One with direct dependencies + subdependencies (pip freeze output)

That's a lock file...

Ok ! That's what I'd do then.

Are you only working on small projects? For reference, if your project is under 100k lines of code, it's small.

By your arbitrary metric, I work on both small and big projects. Not sure how the loc metric relates to the matter though.

Thanks for the link, interesting read.

I still think this is all too convoluted though. I hope an accepted de facto standard for this will emerge at some point.