Structured, Exchangeable lock file format (requirements.txt 2.0?)

[dustin (Dustin Ingram)]

@dstufft

So the only real benefit here, in my opinion, is that maybe something like Heroku can learn to deploy from only that lock file? But it looks like the pipenv integration in Heroku will also work with just a Pipfile instead of a Pipfile.lock , and I expect other providers would do the same. So I don’t feel like there’s a huge win to standardizing the lock format.

I think this is the real advantage to a standardized lock file, and the reason why a given service (say, Google App Engine or Google Cloud Functions) doesn’t currently support Pipfile/Pipfile.lock. As long as the lockfile is an implementation detail of a given tool, service providers not going to build support for N different lockfiles.

Great to hear that Heroku works with just a Pipfile, but I feel like if you’re using a Pipfile without a lockfile, you’re missing out on the most valuable feature (fully specified, deterministic dependencies), so what’s the point?