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
>
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
[Nick wrote:]
>>> However, there *are* folks that have been working on allowing
>>> applications to be defined primarily as Python projects, and then have
>>> the creation of wrapper native installers be a pushbutton exercise,
>>> rather than requiring careful human handholding.
[Nathaniel
On Sat, 4 Aug 2018 at 13:31, Jeroen Demeyer 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
On 31 July 2018 at 08:13, Paul Moore wrote:
> On 30 July 2018 at 23:01, David Cournapeau wrote:
>> Hi,
>>
>> I see that there is almost no mention of private packages index in the
>> packaging guide, and no recommendation on what to use.
>>
>> Currently googling for private packages mostly
On Sat, 4 Aug 2018 at 12:25, Jeroen Demeyer wrote:
>
> On 2018-08-04 13:16, Paul Moore wrote:
> > Can you give a
> > specific example of an end to end process where the packaging
> > toolchain's current behaviour gives demonstrably the wrong result?
>
> Yes I can. I will work out a detailed
On 4 August 2018 at 23:29, Paul Moore wrote:
> On Sat, 4 Aug 2018 at 13:31, Jeroen Demeyer 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
On Sat, 4 Aug 2018 at 10:05, Jeroen Demeyer wrote:
>
> On 2018-08-04 10:34, Paul Moore wrote:
> > Jeroen seemed to say he agreed with this, but
> > I'm not sure I see how that matches his stated requirement for
> > installs to not preserve timestamps...
>
> The way how pip currently works (I
The fact that installs from wheels don't preserve timestamps is a very
good argument that it's OK to NOT preserve timestamps in general. Any
package which would rely on preserving timestamps would already be
broken when installing using a wheel.
By the way, initially I thought that this was a
On 2018-08-04 00:02, Chris Jerdonek wrote:
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
This seems to be about preserving timestamps when extracting wheel files.
There is also an
On Sat, 4 Aug 2018 at 09:18, Chris Jerdonek wrote:
>
> On Sat, Aug 4, 2018 at 1:08 AM, Paul Moore wrote:
> > On Sat, 4 Aug 2018 at 08:35, Jeroen Demeyer wrote:
> >
> >> So both are different issues, and I agree with both: during the source
> >> extraction and build process, you want to preserve
On Sat, Aug 4, 2018 at 1:08 AM, Paul Moore wrote:
> On Sat, 4 Aug 2018 at 08:35, Jeroen Demeyer wrote:
>
>> So both are different issues, and I agree with both: during the source
>> extraction and build process, you want to preserve timestamps as much as
>> possible. But for the installation,
On 2018-08-04 10:34, Paul Moore wrote:
Jeroen seemed to say he agreed with this, but
I'm not sure I see how that matches his stated requirement for
installs to not preserve timestamps...
The way how pip currently works (I assume that this stays the case) is
that it uses a temporary build
13 matches
Mail list logo
