Hello,
I would like to draw attention to https://bugs.python.org/issue32773
Currently, distutils (and everything that uses it, such as setuptools
and pip) installs files with the same timestamp as in the sources (I'm
only discussing copied files, not generated/compiled files). In other
words, it preserves the timestamp when it copies the file from source to
installation directory. There is a comment in the distutils sources
# XXX copy_file by default preserves atime and mtime. IMHO this is
# the right thing to do, but perhaps it should be an option -- in
# particular, a site administrator might want installed files to
# reflect the time of installation rather than the last
# modification time before the installed release.
It just says "IMHO, this is the right thing to do" without any
justification.
Now IMHO, preserving timestamps is NOT the right thing to do: the
timestamp of installed files should be the time of installation.
Autotools (which is probably the most-used installer for open
source/free software projects) does that.
The reason why preserving timestamps is bad is because it breaks
dependency checking: when you install something, you typically want to
rebuild other things depending on it. For .py files, this isn't relevant
(nothing depends on them), but it is relevant for .h files and certain
Cython files.
So I suggested in bpo-32773 to fix this. The main open question is: to
what extent could this break backwards compatibility? Personally, I
cannot imagine a case where it is important that timestamps are preserved.
If it's decided that this should become optional, it should be done on a
per-project basis (and not by the user installing the package). For
example, I would want all my projects to not preserve timestamps.
Suggestions on how to do this (a new argument to setup()?) are welcome.
Jeroen
PS: if you're interested in the history, this goes back to
commit 13ae1c8ff81befcfd0b0ece98ef471cd504642d8
Author: Greg Ward