Unfortunately this workflow is pretty fragile and it will not protect you from any of pip locking shortcomings.

It will basically work only in favorable cases where you have no ambiguous choice, no conflict (A depends on B==1.2.3, C depends on B==2.3.4), no reinstall to consider (git VS non git deps for instance), ... Really pip-tools is not that bad for now, until pip itself moves toward industry standards by default (lock file, deps resolution, reliable version checks, ..)

I can second this method, I use docker to generate my frozen requirements though. This allows you to get a frozen set of requirements from a clean environment without the random stuff that can be installed locally.

https://gist.github.com/kbrownlees/80c1a16aa226e5d52677e011b...

Working on a primarily php project that also has a fair amount of python, a source of frustration has been breakage from sporadic pip package changes. This seems like a reasonable approach to help maintain some sanity.