Python defaults to embed build-time timestamp into .pyc. During loading, python interpreter checks timestamp to decide if .pyc matches the .py file. Since we ship with .pyc files in binpkgs, current we cannot have reproducible python related packages. Python can have .pyc contain hash instead of timestamp. In this mode, python interpreter computes the hash of .py file and check if hash matches the field in .pyc file during loading. So this mode has some performance hit. Debian seems doesn't provide .pyc files, so their binpkgs can be reproducible. Archlinux seems to use hash-based method. See: https://peps.python.org/pep-0552/ https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
(In reply to thssld from comment #0) > Python defaults to embed build-time timestamp into .pyc. During loading, > python interpreter checks timestamp to decide if .pyc matches the .py file. > Since we ship with .pyc files in binpkgs, current we cannot have > reproducible python related packages. I don't get this. We ship both .py and .pyc, and we preserve timestamps, so th files always match. What's the problem?
(In reply to Michał Górny from comment #1) > (In reply to thssld from comment #0) > > Python defaults to embed build-time timestamp into .pyc. During loading, > > python interpreter checks timestamp to decide if .pyc matches the .py file. > > Since we ship with .pyc files in binpkgs, current we cannot have > > reproducible python related packages. > > I don't get this. We ship both .py and .pyc, and we preserve timestamps, so > th files always match. What's the problem? The timestamp embedded in .pyc is the time of build rather than the mtime of .py file. So it differs across builds.
That's not a problem. Python still correctly recognizes the .pyc file as being up-to-date.
