# development


05/17/2023, 3:06 AM
Are there any backends that have to deal with file mtime and/or mode? It looks like the
is similar to
in that it only preserves the executable bit - the mtime and other bits of file mode are not accounted for. For some package types (I'm working on rpm/deb/etc), mode and mtime are significant as they are baked into the package. So, I'm trying to think of a sane way to define defaults for mode / mtime, and I'm hoping that some other backend (or pex?) has already had to deal with this and what solution was used.


05/17/2023, 3:14 AM
I think reproducible builds as a concept will generally use some sentinel value for mtime (e.g. talks about tools reading
to override any default timestamp reading/setting) Using pex as an example of good reproducibility: For timestamps (
is the default)
Copy code
$ pex --help | grep -A7 system-time
  --use-system-time, --no-use-system-time
Use the current system time to generate timestamps for
the new pex. Otherwise, Pex will use midnight on
January 1, 1980. By using system time, the generated
pex will not be reproducible, meaning that if you were
to run `./pex -o` with the same inputs then the new
pex would not be byte-for-byte identical to the
original. (default: False)
For modes: just stats the files:
That is to say, I think pex will ignoring the mtimes of the files that are materialized into sandbox, so it's reproducible no matter what pants does with them


05/17/2023, 3:25 AM
Excellent resource. Thank you. Something like
or even Jan 1, 1980 for the mtime sounds perfect.