# Structured, Exchangeable lock file format (requirements.txt 2.0?) **URL:** \ **Category:** Packaging\ **Created:** [February 12, 2019, 8:37am UTC](https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876 "2019-02-12T08:37:12Z")\ **Posts on this page:** 1\ **Showing post:** 19
**Author:** ![dustin](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dustin/32/149_2.png) [@dustin](https://discuss.python.org/u/dustin)\ **Post date:** [February 12, 2019, 6:43pm UTC](https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/19 "2019-02-12T18:43:03Z")
> [@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? --- _[View the full topic](https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876)._