# PEP 665, take 2 -- A file format to list Python dependencies for reproducibility of an application

**URL:** <https://discuss.python.org/t/pep-665-take-2-a-file-format-to-list-python-dependencies-for-reproducibility-of-an-application/11736>\
**Category:** Packaging\
**Created:** [November 3, 2021, 8:53pm UTC](https://discuss.python.org/t/pep-665-take-2-a-file-format-to-list-python-dependencies-for-reproducibility-of-an-application/11736 "2021-11-03T20:53:46Z")\
**Posts on this page:** 1\
**Showing post:** 24

<div class="post-metadata">

**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\
**Post date:** [November 5, 2021, 10:27pm UTC](https://discuss.python.org/t/pep-665-take-2-a-file-format-to-list-python-dependencies-for-reproducibility-of-an-application/11736/24 "2021-11-05T22:27:40Z")

</div>

> [@Supporting sdists and source trees in PEP 665](https://discuss.python.org/t/supporting-sdists-and-source-trees-in-pep-665/11869/3):
>
> An intermediate step could be recording the source artifact hash (or VCS commit hash) and pin build dependencies, and let the user take conscious responsibility for making sure its build conditions are safe. That would be useful for many users.

Allowing for sdists and source trees is [an open issue](https://www.python.org/dev/peps/pep-0665/#allowing-source-distributions-and-source-trees-to-be-an-opt-in-supported-file-format) (and there are other open issues to discuss as well).

But the trick is how do you pin build dependencies? All you can actually pin is the _builder_, but not what it may need to do _the build_ (i.e. you can pin what is specified using PEP 517, but that isn’t the complete story). It also then makes it so the installer has to have complete resolution logic as you can’t know ahead of time what the source tree will require to be installed once built, and this is very likely true for an sdist as well (unless they fill out their `PKG-INFO`, use core metadata 2.2, and don’t have `Requires-Dist` marked as dynamic). As of right now the installer’s logic is much simpler on purpose so as to not require a complete SAT solver.

> [@dustin](#):
>
> Since we’re talking about reproducibility, what’s the use case for the non-reproducible `created_at` timestamp? The PEP doesn’t address it.

That was an explicit ask in the last round to make it easy to know when the lock file may be out of date based on someone’s personal experience with requirements files.

> [@dustin](#):
>
> While it won’t affect the reproducibility of an application that a `.pylock.toml` file describes, it will affect the bit-for-bit reproducibility of anything that may contain a `.pylock.toml` file.

Good point. Unfortunately there’s no way to resolve that conflict, so we will have to choose which use case is more important.

> [@encukou](#):
>
> Development is one use case of many. Please consider expanding it into something like this

Sure, happy to figure out a way to pull it in.

> [@encukou](#):
>
> This point may be moot if TOML handles the datetime.

That’s the point that @frostming made and it seems like a good point, so I will change the PEP to say the date time must be in UTC but otherwise leave the format requirements to the TOML spec.

---

_[View the full topic](https://discuss.python.org/t/pep-665-take-2-a-file-format-to-list-python-dependencies-for-reproducibility-of-an-application/11736)._