Re: Timestamp of installed files
On 2018-08-04 14:02, Thomas Kluyver wrote:
On Sat, Aug 4, 2018, at 9:34 AM, Paul Moore wrote:
Whether timestamps are preserved by the wheel building process depends on the build system - so the question boils down to "does setup.py bdist_wheel preserve timestamps?" in the case of the setuptools backend - which is really a question for the wheel project. In the more general case, you'd have to ask the same question of flit, and any other backends you cared about.
IIRC, Flit will preserve the timestamps of the files when you build a wheel
For the record: my post wasn't about *building* a wheel, but about *installing* a wheel.
On Sat, 4 Aug 2018 at 13:31, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2018-08-04 14:02, Thomas Kluyver wrote:
On Sat, Aug 4, 2018, at 9:34 AM, Paul Moore wrote:
Whether timestamps are preserved by the wheel building process depends on the build system - so the question boils down to "does setup.py bdist_wheel preserve timestamps?" in the case of the setuptools backend - which is really a question for the wheel project. In the more general case, you'd have to ask the same question of flit, and any other backends you cared about.
IIRC, Flit will preserve the timestamps of the files when you build a wheel
For the record: my post wasn't about *building* a wheel, but about *installing* a wheel.
But given that the current behaviour of pip is to copy the timestamps held in the wheel[1], where those timestamps came from is relevant to the discussion, surely? Paul [1] Or is it? The wheel is expanded into a temporary directory, and then copied from there to the final location. It's only step 2 that has been confirmed to copy timestamps currently. I don't think anyone has checked what the expansion step does.
On 4 August 2018 at 23:29, Paul Moore <p.f.moore@gmail.com> wrote:
On Sat, 4 Aug 2018 at 13:31, Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
For the record: my post wasn't about *building* a wheel, but about *installing* a wheel.
But given that the current behaviour of pip is to copy the timestamps held in the wheel[1], where those timestamps came from is relevant to the discussion, surely?
Not really. As a simple case where getting file timestamps to change is important, consider this scenario: 1. A dev is hacking on an extension that depends on NumPy while they have version 1.15 installed. 2. They realise they're supposed to be supporting NumPy 1.14+, so they downgrade to the older version 3. They kick off a rebuild of their extension, since they want to recompile against the NumPy 1.14 headers This only works if step 2 changes the timestamp on all the NumPy headers to be *newer* than the previously installed NumPy 1.15 headers. Regardless of how the wheels were generated, it's a pretty safe bet the timestamps in the NumPy 1.15 wheel are going to be newer than the ones in the NumPy 1.14 wheel, so getting the latter to be newer pretty much requires ignoring the wheel, and using the installation time instead. It isn't a disaster if it doesn't (since C/C++ folks are used to needing to forcibly rebuild the world after upgrading or downgrading dependencies), but it's still a nice developer quality of life enhancement if "downgrade + incremental rebuild" just works most of the time. None of this affects reproducible builds, as the whole point of SOURCE_DATE_EPOCH is to allow everything that affects the final output artifacts to *ignore* the modification times on any checked out, generated or unpacked files. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Jeroen Demeyer -
Nick Coghlan -
Paul Moore