3

I appreciate that in many circumstances it is important to explicitly state what dependency versions we are working with and that this thus applies to the nested dependencies as well.

However, it becomes very messy when we decide to remove a dependency and need to use something like pideptree to find out if it had any dependencies of its own which we also installed and additionally make sure that these nested dependencies are not being used by our other first-level dependencies.

Assuming we don't need to freeze our dependency versions what is the advantage of including the nested dependencies rather than just letting pip take care of it for us?

Ludo
  • 2,307
  • 2
  • 27
  • 58

2 Answers2

5

People actually don't do that. requirements.txt really should list your dependencies without nested dependencies. Pinned dependencies are usually put in another file:

pip freeze > requirements-freeze.txt

If people pin dependencies in requirements.txt that's not exactly a bug but not the best practice for sure.

phd
  • 82,685
  • 13
  • 120
  • 165
2

Actually, you are right. If you have tried pipenv, you will find it is the thing what you want.

The reason why people write all nested dependencies in requirements.txt is just because pip freeze > requirements.txt will list all installed packages.

And pipenv use a better way to manage dependencies which likes npm or yarn so you can easily delete all nested dependencies for a top module.

But it is still reasonable to list all nested dependencies. A case I met before, that is a third-party A rely on another third-party B. And the dependency of B in A is B>=4.10.0. But in B==4.12.0, some packages were migrated from one module to another module. As the importation broke so that the whole lib A broke too.

Sraw
  • 18,892
  • 11
  • 54
  • 87