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.

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.

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?

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.

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

Yes, and yes

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.

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.

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.

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

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.