[Distutils] Re: Timestamp of installed files
I'm not sure how relevant it is, but this issue was recently filed on
pip's issue tracker ("Reproducible installs"):
https://github.com/pypa/pip/issues/5648
Is there any overlap?
There is also an older (closed) pip issue that might be relevant
("Preserving timestamps on copy"):
https://github.com/pypa/pip/issues/3201
--Chris
On Fri, Aug 3, 2018 at 2:14 PM, Jeroen Demeyer wrote:
> 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
> Date: Mon Mar 22 14:55:25 1999 +
>
> First checkin of real Distutils command modules.
>
> So yes, I want to change a 19-year old "feature".
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/4FHEGHZYWCDRWVPGYLAU5VUS5BAX73MO/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/NY36MB4HBXKURKQKT7ARRI6AP4KKQ445/
[Distutils] Timestamp of installed files
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 Date: Mon Mar 22 14:55:25 1999 + First checkin of real Distutils command modules. So yes, I want to change a 19-year old "feature". -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/4FHEGHZYWCDRWVPGYLAU5VUS5BAX73MO/
[Distutils] PEP 541 Regarding emd
Dear Admin, I am writing to you regarding the Package Index name emd. I am a PhD student at the University of Central Florida and for my dissertation, I have recently developed a Python software, Evolutionary Model Discovery, which I am assembling into a package, EMD. https://github.com/chathika/EMD However, I noticed that there is already a package named emd on pypi.org. This package seems abandoned with just one release in February 2012 and no contact information about the author, https://pypi.org/project/emd/1.0/#history . I read about PEP 541 https://www.python.org/dev/peps/pep-0541/ and was curious as to if it is still possible that I can acquire the package name EMD. I wanted to make sure of this before I went ahead with the name EMD for my package, please. Looking forward to your reply. Best Regards, Chathika Gunaratne Graduate Research Assistant, Complex Adaptive Systems Lab University of Central Florida, Room 314, Engineering II, 12800 Pegasus Dr., Orlando, FL 32816-2993 -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/PEZGHY6VIIVQPEEAL5US3GJ2BNDCBEFE/
[Distutils] PEP 541
abou5alil1...@gmail.com -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/HDW3KWWYEKHEZ75UR6US4P6EKUSMRFEU/
