When a Python project is installed, distutils copies the files from the build to install directory using copy_file(). In this copy operation, timestamps are preserved. In other words, the timestamp of the installed file equals the timestamp of the source file.

By contrast, autotools does not preserve timestamps: the timestamp of the installed files equals the time of installation. This makes more sense because of dependency checking: if you reinstall a package, you typically want to rebuild everything depending on that package.

This issue is mostly relevant for installing .h files: most build systems (including distutils itself) provide a way to recompile C/C++ source files if they depend on a changed header file. But that only works if the timestamp of the header is updated when it is installed.

Note that ./command/build_py.py contains a comment

        # 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.

but without justification.

Will an option be added to copy_file() function? if we did we could probably make it preserve the times by default and have an -- option to make it update?

This is a bug report and not a feature request. I don't think that there should be an option. It should just do the right thing, which is NOT preserving timestamps.

That's the right thing in your opinion[*], but probably not in the opinion of others, thus the need for an option.  There is also backward compatibility to be considered.

That's why I said to have the default be the old setting, so that any previous setups wouldn't need to changes (aka backward compat.) the option would give people the "option" to choose.

I can tackle this if it's alright?

I am genuinely curious to hear a good reason why timestamps should be preserved by distutils. I cannot really imagine what could possibly break. As I said, this is the standard for many non-Python projects and it seems to work just fine.

I can see one potential backwards-compatibility issue for projects abusing distutils to do things unrelated to installing Python packages. So I understand that you don't want to change the default in the copy_file() function, but only in the methods calling that function.

so what you're proposing, is that the function copy_file() itself, use defaults, but make it so that any functions that reference it not save the timing?, if so wouldn't that still require an internal option?

> if so wouldn't that still require an internal option?

No, you just need to change the calls to the copy_file() function to add the keyword argument preserve_times=False

If you agree, then I could easily provide a patch.

We have a strong backward compatibility policy, especially for distutils, so even though you can't imagine a use case I think we should keep the default the same.

You could try lobbying the folks at pypa and see if they disagree with me, since the opinion of the python core devs there would overrule me :)  Or perhaps one or more of the other nosy people here will chime in.

would it be ok for me to make a patch for this as practice?, I will be making a PR though, I will be making the -- option available for backward compatibility.

I started a discussion at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/thread/4FHEGHZYWCDRWVPGYLAU5VUS5BAX73MO/

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools