[vmsp]

pip-tools is almost never mentioned because it's boring but great. I always default to it.

https://github.com/jazzband/pip-tools

[mjw1007]

Yes.

In particular, the way it effectively gets you to "I control the lock file; it will be altered when I explicitly request it and never as a side-effect of any other action".

For some reason many other languages' systems (which have had opportunities to learn from others' mistakes) don't seem to treat this as a requirement.

[mariocesar]

Yes !! I just create a Makefile target and pip-tools is all I need. I create a requirements.in and that is all. So far never feel that has to be more complicated than that. And when I want to upgrade a package I update the requirements.in if I need to and run `make -B` for this:

  default: requirements-develop.txt
    pip install -r requirements-develop.txt

  requirements.txt:
    pip-compile -v requirements.in

  requirements-develop.txt: requirements.txt
    pip-compile -v requirements-develop.in

I so nice to just write `make` than doing all the Poetry, Pipenv stuff, that honestly I feel is not adding nothing really really useful to the workflow.

[autograd]

Does it pin versions of 2nd degree dependencies too? Like pip freeze would do? Also, when you remove a package, does it know to clear packages that were its deps and are not needed anymore?

[mjw1007]

pip-tools can do both of those, yes.

For the second, pip-compile computes the new requirements.txt (which is effectively the lockfile) from scratch, and pip-sync (not shown in that Makefile fragment) removes packages that are no longer listed there.

[autograd]

Thanks a lot for the reply. I'll include it some time soon in the article update

[mariocesar]

Yes, and yes

[mumblemumble]

I came to the comments to say exactly this.

There's a decent summary of why someone might still prefer pip-tools even in a world where pipenv and poetry exist here: https://hynek.me/articles/python-app-deps-2018/

For my purposes, the primary downside of this approach is that adding dependencies takes slightly more effort, because you have to edit a file and then execute a shell command, rather than just executing a shell command. But managing dependencies takes up about 0.001% of my time, so this is not an area where I have much to gain by micro-optimizing my workflow.

I do, on the other hand, have a lot to lose by switching to something that's newer and shinier and less stable.

[polyrand]

I fully agree. But I see editing the file manually an advantage. I can pip install whatever I want and then I only need to worry about having a clean requirements.in file.

With that, I know the compiled requirements.txt will only have what I need. Now it is just pip install -r requirements.txt or pip-sync.

[mumblemumble]

That's a very good point. I don't think it had even occurred to me that it would be more difficult with pipenv or poetry. But, admittedly, I haven't made it far into either of them - a little noodling around, just enough to figure out that they don't really address any pain points for me.

[mariokostelac]

Thanks for mentioning it! How would you compare it to the other tools from the original post?

[Groxx]

Pipenv is almost exactly pip-tools + venv + a custom UI over the two. And slightly easier / more automatic venv management.

From the times I've looked at it (almost a year ago and older): pip-tools is / was the core of Pipenv... but it has been a fair distance ahead in terms of bug fixes and usable output for diagnosing conflicts. It seemed like pipenv forked from pip-tools a couple years prior, and didn't keep up.

Given that, I've been a happy user of v(irtual)env and pip-tools. Pipenv has remained on the "maybe some day, when it's better" side of things, since I think it does have potential.