reproducibility

reproducibility

[Federico Beffa]

Hi,

I've noticed that a derivation is a function of the order of the
inputs. As an example, the following two input orders give rise to two
distinct derivations:

A)

    (inputs
     `(("texlive" ,texlive)
       ("texinfo" ,texinfo)
       ("m4" ,m4)
       ("libx11" ,libx11))

B)
    (inputs
     `(("texinfo" ,texinfo)
       ("texlive" ,texlive)
       ("m4" ,m4)
       ("libx11" ,libx11))

Is this intentional?

Regards,
Fede

Re: reproducibility

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> I've noticed that a derivation is a function of the order of the
> inputs. As an example, the following two input orders give rise to two
> distinct derivations:
>
> A)
>
>     (inputs
>      `(("texlive" ,texlive)
>        ("texinfo" ,texinfo)
>        ("m4" ,m4)
>        ("libx11" ,libx11))
>
> B)
>     (inputs
>      `(("texinfo" ,texinfo)
>        ("texlive" ,texlive)
>        ("m4" ,m4)
>        ("libx11" ,libx11))
>
> Is this intentional?

Yes.  There are several places where order matters, most importantly
search paths, and these are computed from the input lists.

Ludo’.

Re: reproducibility

[Federico Beffa]

On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> I've noticed that a derivation is a function of the order of the
>> inputs. As an example, the following two input orders give rise to two
>> distinct derivations:
>>
>> A)
>>
>>     (inputs
>>      `(("texlive" ,texlive)
>>        ("texinfo" ,texinfo)
>>        ("m4" ,m4)
>>        ("libx11" ,libx11))
>>
>> B)
>>     (inputs
>>      `(("texinfo" ,texinfo)
>>        ("texlive" ,texlive)
>>        ("m4" ,m4)
>>        ("libx11" ,libx11))
>>
>> Is this intentional?
>
> Yes.  There are several places where order matters, most importantly
> search paths, and these are computed from the input lists.

If order matters, it would probably be more robust to force internally
a specific order rather than relying on the (often random) order
defined in a package recipe (possibly created by an importer, ...).

Fede

Re: reproducibility

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>>> I've noticed that a derivation is a function of the order of the
>>> inputs. As an example, the following two input orders give rise to two
>>> distinct derivations:
>>>
>>> A)
>>>
>>>     (inputs
>>>      `(("texlive" ,texlive)
>>>        ("texinfo" ,texinfo)
>>>        ("m4" ,m4)
>>>        ("libx11" ,libx11))
>>>
>>> B)
>>>     (inputs
>>>      `(("texinfo" ,texinfo)
>>>        ("texlive" ,texlive)
>>>        ("m4" ,m4)
>>>        ("libx11" ,libx11))
>>>
>>> Is this intentional?
>>
>> Yes.  There are several places where order matters, most importantly
>> search paths, and these are computed from the input lists.
>
> If order matters, it would probably be more robust to force internally
> a specific order rather than relying on the (often random) order
> defined in a package recipe (possibly created by an importer, ...).

Most of the time any order would work, but I can imagine situations
where the packager could purposefully choose a specific order.  So I’d
rather not do any automatic sorting, if that’s what you have in mind.

Thanks,
Ludo’.

Re: reproducibility

[Federico Beffa]

On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Federico Beffa <beffa@ieee.org> skribis:
>>>
>>>> I've noticed that a derivation is a function of the order of the
>>>> inputs. As an example, the following two input orders give rise to two
>>>> distinct derivations:
>>>>
>>>> A)
>>>>
>>>>     (inputs
>>>>      `(("texlive" ,texlive)
>>>>        ("texinfo" ,texinfo)
>>>>        ("m4" ,m4)
>>>>        ("libx11" ,libx11))
>>>>
>>>> B)
>>>>     (inputs
>>>>      `(("texinfo" ,texinfo)
>>>>        ("texlive" ,texlive)
>>>>        ("m4" ,m4)
>>>>        ("libx11" ,libx11))
>>>>
>>>> Is this intentional?
>>>
>>> Yes.  There are several places where order matters, most importantly
>>> search paths, and these are computed from the input lists.
>>
>> If order matters, it would probably be more robust to force internally
>> a specific order rather than relying on the (often random) order
>> defined in a package recipe (possibly created by an importer, ...).
>
> Most of the time any order would work, but I can imagine situations
> where the packager could purposefully choose a specific order.  So I’d
> rather not do any automatic sorting, if that’s what you have in mind.

Just out of curiosity, could you provide a concrete example where the
order is purposefully specified.

Thanks,
Fede

Re: reproducibility

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

On Wed, 13 Jan 2016 09:13:25 +0100
Federico Beffa <beffa@ieee.org> wrote:

> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> 
> Just out of curiosity, could you provide a concrete example where the
> order is purposefully specified.
> 
> Thanks,
> Fede
> 

I haven't had time (since reading this) to test if the order matters or not,
but some of the openstack packages say they care about order:
https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/test-requirements.txt?h=2.0.0

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: reproducibility

[Federico Beffa]

On Wed, Jan 13, 2016 at 10:15 AM, Efraim Flashner <efraim@flashner.co.il> wrote:
> On Wed, 13 Jan 2016 09:13:25 +0100
> Federico Beffa <beffa@ieee.org> wrote:
>
>> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>  [...]
>>  [...]
>>  [...]
>>  [...]
>>  [...]
>>  [...]
>>  [...]
>>
>> Just out of curiosity, could you provide a concrete example where the
>> order is purposefully specified.
>>
>> Thanks,
>> Fede
>>
>
> I haven't had time (since reading this) to test if the order matters or not,
> but some of the openstack packages say they care about order:
> https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/test-requirements.txt?h=2.0.0

Reading the comment sounds like its because pip installs packages
sequentially. Sounds like a different approach from what we are doing.

Anyway, thanks for the pointer.
Regards,
Fede

Re: reproducibility

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Federico Beffa <beffa@ieee.org> skribis:
>>
>>> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>> Federico Beffa <beffa@ieee.org> skribis:
>>>>
>>>>> I've noticed that a derivation is a function of the order of the
>>>>> inputs. As an example, the following two input orders give rise to two
>>>>> distinct derivations:
>>>>>
>>>>> A)
>>>>>
>>>>>     (inputs
>>>>>      `(("texlive" ,texlive)
>>>>>        ("texinfo" ,texinfo)
>>>>>        ("m4" ,m4)
>>>>>        ("libx11" ,libx11))
>>>>>
>>>>> B)
>>>>>     (inputs
>>>>>      `(("texinfo" ,texinfo)
>>>>>        ("texlive" ,texlive)
>>>>>        ("m4" ,m4)
>>>>>        ("libx11" ,libx11))
>>>>>
>>>>> Is this intentional?
>>>>
>>>> Yes.  There are several places where order matters, most importantly
>>>> search paths, and these are computed from the input lists.
>>>
>>> If order matters, it would probably be more robust to force internally
>>> a specific order rather than relying on the (often random) order
>>> defined in a package recipe (possibly created by an importer, ...).
>>
>> Most of the time any order would work, but I can imagine situations
>> where the packager could purposefully choose a specific order.  So I’d
>> rather not do any automatic sorting, if that’s what you have in mind.
>
> Just out of curiosity, could you provide a concrete example where the
> order is purposefully specified.

No specific example, sorry, but it’s plausible IMO.  With enough CPU
power, we could try rebuilding everything with a random order and see
what breaks.

Thanks,
Ludo’.

Re: reproducibility

[Federico Beffa]

On Wed, Jan 13, 2016 at 2:56 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Federico Beffa <beffa@ieee.org> skribis:
>>>
>>>> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>>> Federico Beffa <beffa@ieee.org> skribis:
>>>>>
>>>>>> I've noticed that a derivation is a function of the order of the
>>>>>> inputs. As an example, the following two input orders give rise to two
>>>>>> distinct derivations:
>>>>>>
>>>>>> A)
>>>>>>
>>>>>>     (inputs
>>>>>>      `(("texlive" ,texlive)
>>>>>>        ("texinfo" ,texinfo)
>>>>>>        ("m4" ,m4)
>>>>>>        ("libx11" ,libx11))
>>>>>>
>>>>>> B)
>>>>>>     (inputs
>>>>>>      `(("texinfo" ,texinfo)
>>>>>>        ("texlive" ,texlive)
>>>>>>        ("m4" ,m4)
>>>>>>        ("libx11" ,libx11))
>>>>>>
>>>>>> Is this intentional?
>>>>>
>>>>> Yes.  There are several places where order matters, most importantly
>>>>> search paths, and these are computed from the input lists.
>>>>
>>>> If order matters, it would probably be more robust to force internally
>>>> a specific order rather than relying on the (often random) order
>>>> defined in a package recipe (possibly created by an importer, ...).
>>>
>>> Most of the time any order would work, but I can imagine situations
>>> where the packager could purposefully choose a specific order.  So I’d
>>> rather not do any automatic sorting, if that’s what you have in mind.
>>
>> Just out of curiosity, could you provide a concrete example where the
>> order is purposefully specified.
>
> No specific example, sorry, but it’s plausible IMO.  With enough CPU
> power, we could try rebuilding everything with a random order and see
> what breaks.

I guess that's not necessary... I was just trying to learn something.

Thanks,
Fede