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.

classification
Title: distutils should NOT preserve timestamps
Type: enhancement Stage: resolved
Components: Distutils Versions: Python 3.8
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: dstufft, eric.araujo, erik.bray, jayyin11043, jdemeyer, matrixise, r.david.murray, steve.dower
Priority: normal Keywords: patch

Created on 2018-02-05 16:01 by jdemeyer, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 5584 closed jayyin11043, 2018-02-07 22:43
PR 5690 closed jayyin11043, 2018-02-15 05:31
Messages (13)
msg311673 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2018-02-05 16:01
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.
msg311691 - (view) Author: Jay Yin (jayyin11043) * Date: 2018-02-05 20:49
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?
msg311739 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2018-02-06 18:49
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.
msg311741 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2018-02-06 19:11
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.
msg311742 - (view) Author: Jay Yin (jayyin11043) * Date: 2018-02-06 19:28
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.
msg311743 - (view) Author: Jay Yin (jayyin11043) * Date: 2018-02-06 19:29
I can tackle this if it's alright?
msg311744 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2018-02-06 19:29
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.
msg311745 - (view) Author: Jay Yin (jayyin11043) * Date: 2018-02-06 19:39
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?
msg311746 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2018-02-06 19:43
> 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.
msg311748 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2018-02-06 20:02
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.
msg311808 - (view) Author: Jay Yin (jayyin11043) * Date: 2018-02-07 21:59
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.
msg323079 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2018-08-03 21:15
I started a discussion at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/thread/4FHEGHZYWCDRWVPGYLAU5VUS5BAX73MO/
msg386344 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-02-03 18:19
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
History
Date User Action Args
2022-04-11 14:58:57adminsetgithub: 76954
2021-02-03 18:19:34steve.dowersetstatus: open -> closed

nosy: + steve.dower
messages: + msg386344

resolution: out of date
stage: patch review -> resolved
2018-08-03 21:15:22jdemeyersetmessages: + msg323079
2018-02-15 05:31:19jayyin11043setpull_requests: + pull_request5483
2018-02-07 22:43:54jayyin11043setkeywords: + patch
stage: patch review
pull_requests: + pull_request5401
2018-02-07 21:59:17jayyin11043setmessages: + msg311808
2018-02-06 20:02:16r.david.murraysettype: enhancement
messages: + msg311748
versions: - Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7
2018-02-06 19:43:11jdemeyersetmessages: + msg311746
2018-02-06 19:39:17jayyin11043setmessages: + msg311745
2018-02-06 19:29:48jdemeyersetmessages: + msg311744
2018-02-06 19:29:02jayyin11043setmessages: + msg311743
2018-02-06 19:28:24jayyin11043setmessages: + msg311742
2018-02-06 19:11:23r.david.murraysetnosy: + r.david.murray
messages: + msg311741
2018-02-06 18:49:54jdemeyersetmessages: + msg311739
2018-02-05 20:49:52jayyin11043setnosy: + jayyin11043
messages: + msg311691
2018-02-05 16:43:14matrixisesetnosy: + matrixise
2018-02-05 16:01:16jdemeyercreate