Add the git commit id to the generation information

Add the git commit id to the generation information

[Roel Janssen]

Dear Guix,

I have a feature request.

When I run 'guix pull', install a package, run 'guix pull' again (on
another day), and install another package, I'd get two generations:

> Generation 181  May 22 2017 11:47:37
>  + haunt        0.2.1   out     /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>
> Generation 182  May 24 2017 09:52:06    (current)
>  + guile-commonmark     0.1     out     /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1

Now, if I'd like to go to the Guix packages source code of generation
181, I can only guess at which actual state of the Guix repository this
was, because this timestamp is the timestamp of creating the generation,
not the timestamp of the Guix package state.  So, I'd like to propose to
add the commit id to the generation like so:

> Generation 181  May 22 2017 11:47:37    (ae548434337cddf9677a4cd52b9370810b2cc9b6)
>  + haunt        0.2.1   out     /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>
> Generation 182  May 24 2017 09:52:06    (current)
>  + guile-commonmark     0.1     out     /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1

So, 'current' is the one that is installed at that time.  Any other
should be traceable through the git commit ID.

This would probably require us to have the repository information
available when building the tarball that will be downloaded by 'guix
pull'.  I think this feature is very important because it makes the
generations traceable to the Guix source code, which is needed for
reproducing the same generation.

Is this something we could make?  And can we live with the implicit
requirement to have the git repository information available when
building the source tarballs used by 'guix pull'?

Kind regards,
Roel Janssen

Re: Add the git commit id to the generation information

[Ricardo Wurmus]

Hi Roel,

> I have a feature request.
>
> When I run 'guix pull', install a package, run 'guix pull' again (on
> another day), and install another package, I'd get two generations:
>
>> Generation 181  May 22 2017 11:47:37
>>  + haunt        0.2.1   out     /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>
>> Generation 182  May 24 2017 09:52:06    (current)
>>  + guile-commonmark     0.1     out     /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>
> Now, if I'd like to go to the Guix packages source code of generation
> 181, I can only guess at which actual state of the Guix repository this
> was, because this timestamp is the timestamp of creating the generation,
> not the timestamp of the Guix package state.  So, I'd like to propose to
> add the commit id to the generation like so:
>
>> Generation 181  May 22 2017 11:47:37    (ae548434337cddf9677a4cd52b9370810b2cc9b6)
>>  + haunt        0.2.1   out     /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>
>> Generation 182  May 24 2017 09:52:06    (current)
>>  + guile-commonmark     0.1     out     /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1

What would be the expected behaviour in the presence of
GUIX_PACKAGE_PATH?  I could have had GUIX_PACKAGE_PATH set pointing to a
module containing a custom variant of haunt.

I do agree that it would be very useful to know more about the state of
Guix for any given generation.  However, that state is more complex than
a single commit.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Add the git commit id to the generation information

[Roel Janssen]

Ricardo Wurmus writes:

> Hi Roel,
>
>> I have a feature request.
>>
>> When I run 'guix pull', install a package, run 'guix pull' again (on
>> another day), and install another package, I'd get two generations:
>>
>>> Generation 181  May 22 2017 11:47:37
>>>  + haunt        0.2.1   out     /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>>
>>> Generation 182  May 24 2017 09:52:06    (current)
>>>  + guile-commonmark     0.1     out     /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>>
>> Now, if I'd like to go to the Guix packages source code of generation
>> 181, I can only guess at which actual state of the Guix repository this
>> was, because this timestamp is the timestamp of creating the generation,
>> not the timestamp of the Guix package state.  So, I'd like to propose to
>> add the commit id to the generation like so:
>>
>>> Generation 181  May 22 2017 11:47:37    (ae548434337cddf9677a4cd52b9370810b2cc9b6)
>>>  + haunt        0.2.1   out     /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>>
>>> Generation 182  May 24 2017 09:52:06    (current)
>>>  + guile-commonmark     0.1     out     /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>
> What would be the expected behaviour in the presence of
> GUIX_PACKAGE_PATH?  I could have had GUIX_PACKAGE_PATH set pointing to a
> module containing a custom variant of haunt.
>
> I do agree that it would be very useful to know more about the state of
> Guix for any given generation.  However, that state is more complex than
> a single commit.

Oh, indeed..  Any suggestions?

My other thought on this, is to add a tagging mechanism, that users can
simply add tags to a generation, of which one could be the commit id.

I think that having the upstream git commit ID already improves the
situation.  Adding external repositories is not something the upstream
distribution can take care of.  Maybe if we would add a different, more
formal way of allowing external repositories, that could be dealt with
more easily.  (Is this what 'channels' could do?)

Kind regards,
Roel Janssen

Re: Add the git commit id to the generation information

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ricardo Wurmus writes:
>
>> Hi Roel,
>>
>>> I have a feature request.
>>>
>>> When I run 'guix pull', install a package, run 'guix pull' again (on
>>> another day), and install another package, I'd get two generations:
>>>
>>>> Generation 181  May 22 2017 11:47:37
>>>>  + haunt        0.2.1   out     /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>>>
>>>> Generation 182  May 24 2017 09:52:06    (current)
>>>>  + guile-commonmark     0.1     out     /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>>>
>>> Now, if I'd like to go to the Guix packages source code of generation
>>> 181, I can only guess at which actual state of the Guix repository this
>>> was, because this timestamp is the timestamp of creating the generation,
>>> not the timestamp of the Guix package state.  So, I'd like to propose to
>>> add the commit id to the generation like so:
>>>
>>>> Generation 181  May 22 2017 11:47:37    (ae548434337cddf9677a4cd52b9370810b2cc9b6)
>>>>  + haunt        0.2.1   out     /gnu/store/x2bkpzrdbaxavl29r2xg0fip1jjici9q-haunt-0.2.1
>>>>
>>>> Generation 182  May 24 2017 09:52:06    (current)
>>>>  + guile-commonmark     0.1     out     /gnu/store/k8vq65czfb8k4hvvjvsca34scd9xsxik-guile-commonmark-0.1
>>
>> What would be the expected behaviour in the presence of
>> GUIX_PACKAGE_PATH?  I could have had GUIX_PACKAGE_PATH set pointing to a
>> module containing a custom variant of haunt.
>>
>> I do agree that it would be very useful to know more about the state of
>> Guix for any given generation.  However, that state is more complex than
>> a single commit.
>
> Oh, indeed..  Any suggestions?

I think this is one of the things that channels mean to address.

As a first step, once ‘guix pull’ uses Guile-Git, we can at least record
the commit of Guix.

Ludo’.