https://reproducible-builds.org/ # `SOURCE_DATE_EPOCH` [Thu, 09 Aug 1990 14:25:15 +0000 (1990-08-09)](https://hg.python.org/cpython/rev/3cd033e6b530) [From `git log`](https://reproducible-builds.org/docs/source-date-epoch/) Adding core metadata for `PKG-INFO` to record the sdist's last modification date could be used for `SOURCE_DATE_EPOCH` when building wheels. It should be to the second to avoid precision differences in file systems and having to choose when a timestamp has more accuracy than is supported (e.g. round or floor?). Because the last modification time is **very** likely to be calculated, it's effectively always dynamic. As such it would make more sense to store outside of `PKG-INFO`. Unfortunately, sdists have no other structured data that's created by build back-end so there isn't another place to store it (without expanding what an sdist is). It's also then the only way for the information to propagate to wheels. # Source origin Core metadata to record where the source came from (VCS repo and commit [like for direct URLs](https://packaging.python.org/en/latest/specifications/direct-url-data-structure/#vcs-urls)). Since this is static information for the project that a person knows it can be specified in `pyproject.toml`. # Potential issues Tools that use dynamic information from the state of a source checkout may not work ina reproducible way (e.g. dynamic version calculation based on what tags exist). The necessary data needs to flow from the Source tree to the final distribution file no matter what path the source takes. This allows for reproducible builds no matter which point you're at in the flow. ```mermaid flowchart LR source((Source tree)) sdist wheel distro((Distribution file)) source --> sdist sdist --> wheel source --> wheel sdist --> distro wheel --> distro ```