This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bmwiedemann
Recipients Alexandru Ardelean, Ray Donnelly, barry, benjamin.peterson, bmwiedemann, brett.cannon, dstufft, eric.araujo, eric.smith, eschwartz, vstinner, yan12125
Date 2018-01-15.12:56:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1516020993.5.0.467229070634.issue29708@psf.upfronthosting.co.za>
In-reply-to
Content
I think, there is no single nice and clean solution with time-based .pyc files, but to get a whole distribution to build reproducibly, there are two other ways:

1) if the SOURCE_DATE_EPOCH environment variable is set,
make hash-based .pyc files the default.

2) instead of storing .py mtime in the .pyc header, use the .pyc's filesystem mtime value - also making it more available to users.
Not sure if this would have side-effects or cause regressions.

on the side-issue: IMHO checking exact mtimes is the right thing to do, because sometimes users will copy back old .py files and expect mismatching .pyc files to not be used.
History
Date User Action Args
2018-01-15 12:56:33bmwiedemannsetrecipients: + bmwiedemann, barry, brett.cannon, vstinner, eric.smith, benjamin.peterson, eric.araujo, dstufft, yan12125, Alexandru Ardelean, Ray Donnelly, eschwartz
2018-01-15 12:56:33bmwiedemannsetmessageid: <1516020993.5.0.467229070634.issue29708@psf.upfronthosting.co.za>
2018-01-15 12:56:33bmwiedemannlinkissue29708 messages
2018-01-15 12:56:33bmwiedemanncreate