guix describe -p and Guix commit?

guix describe -p and Guix commit?

[zimoun]

Dear,

How to track from which channel and commit the packages in a profile come from?

For example, today (time T) I run:
  guix package -i emacs guile -p my-env
And I forgot to store the result of "guix describe".

Months later, and after several "guix pull" and not changing the
profile "my-env", I would like to reproduce this exact profile on
another machine.

It is easy to extract the version of Emacs and Guile:
  guix describe -p my-env

So I can dig in the git history to find the commit introducing the
specific version of Emacs and Guile. Well it is not convenient. :-)
but doable. Then, I run:
  guix pull --commit=<hash>
  guix package -i emacs guile -p my-new-env

It is also possible to extract the hashes in the store, reading the
file my-env/manifest and my-new-env/manifest.
And they are not the same. The Guix version that I just pulled should
be anterior to the one at time T. Because maybe something in the
dependencies of Emacs or Guile has changed.

Well, I can list all the pulls with "guix pull" and then guess some
commit. But it is not convenient, neither.

What I would expect is:
 guix describe -p my-env
Generation 5   Sep 20 2019 17:21:30
emacs 26.2 asdf12
guile 2.2.4 z56qwe

(for example, I updated only Emacs once, 3 times Guile)


What do you think?
Do it make sense?


All the best,
simon


All the best,
simon

Re: guix describe -p and Guix commit?

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> How to track from which channel and commit the packages in a profile come from?

Pro tip: open the ‘manifest’ file of the profile, and search for
“provenance”.  You’ll see things like:

--8<---------------cut here---------------start------------->8---
     ("openssl"
      "1.1.1d"
      "out"
      "/gnu/store/4is5a8hy20rkaq4q08vxf1b355vw0fjg-openssl-1.1.1d"
      (propagated-inputs ())
      (search-paths
        (("SSL_CERT_DIR"
          ("etc/ssl/certs")
          #f
          directory
          #f)
         ("SSL_CERT_FILE"
          ("etc/ssl/certs/ca-certificates.crt")
          #f
          regular
          #f)))
      (properties
        (provenance     ;;<- this!
          (repository
            (version 0)
            (url "https://git.savannah.gnu.org/git/guix.git")
            (branch "master")
            (commit
              "18a613fb29bf053b344bca585e78a2cf26b44469")))))
--8<---------------cut here---------------end--------------->8---

It’s an undocumented and unused feature, mostly because I wouldn’t know
how to expose it at the CLI level.  Ideas welcome!

> What I would expect is:
>  guix describe -p my-env
> Generation 5   Sep 20 2019 17:21:30
> emacs 26.2 asdf12
> guile 2.2.4 z56qwe

This seems to be a mixture of ‘guix describe’ and ‘guix package -I’,
right?  I’m not sure what you’re expecting here.

Thanks,
Ludo’.

Re: guix describe -p and Guix commit?

[zimoun]

Hi Ludo,

Thank you for explaining.

On Tue, 24 Sep 2019 at 10:06, Ludovic Courtès <ludo@gnu.org> wrote:

> zimoun <zimon.toutoune@gmail.com> skribis:
>
> > How to track from which channel and commit the packages in a profile come from?
>
> Pro tip: open the ‘manifest’ file of the profile, and search for
> “provenance”.  You’ll see things like:

Oups! I scrolled this file but I missed the feature.
It is what I have looking for. :-)


> It’s an undocumented and unused feature, mostly because I wouldn’t know
> how to expose it at the CLI level.  Ideas welcome!

The easy CLI modification is "guix package --list-installed" to expose
the commit and URI (and branch).
I will give a try.

One step further: the record <manifest-entry> should be compliant with
the option file '-f' or manifest '-m' of "guix package" (or "guix
pack").
Say, I created a profile, did some pulls, installed and removed
packaged. Now I would like to easy "reproduce" this messy
computational environment to another machine. Say I copy
'<profile>/manifest' to 'my-mess', then if I can run "guix package -p
my-profile -m my-mess" (or "guix pack"), I would be happy. ;-)
Or if some compliance of '<profile>/manifest' and the option '-m'  is
not possible, perhaps a way to convert this <profile>/manifest into a
'-m' manifest.
Maybe, is it already possible? Re-instatiate the tools from a profile.

What do you think?
Does it make sense?

> > What I would expect is:
> >  guix describe -p my-env
> > Generation 5   Sep 20 2019 17:21:30
> > emacs 26.2 asdf12
> > guile 2.2.4 z56qwe
>
> This seems to be a mixture of ‘guix describe’ and ‘guix package -I’,
> right?  I’m not sure what you’re expecting here.

You have right. My mind was not clear. :-)
I am expecting a better "guix package --list-installed". :-)


All the best,
simon

Re: guix describe -p and Guix commit?

[Ludovic Courtès]

Hello!

zimoun <zimon.toutoune@gmail.com> skribis:

> On Tue, 24 Sep 2019 at 10:06, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> zimoun <zimon.toutoune@gmail.com> skribis:
>>
>> > How to track from which channel and commit the packages in a profile come from?
>>
>> Pro tip: open the ‘manifest’ file of the profile, and search for
>> “provenance”.  You’ll see things like:
>
> Oups! I scrolled this file but I missed the feature.
> It is what I have looking for. :-)
>
>
>> It’s an undocumented and unused feature, mostly because I wouldn’t know
>> how to expose it at the CLI level.  Ideas welcome!
>
> The easy CLI modification is "guix package --list-installed" to expose
> the commit and URI (and branch).
> I will give a try.

Though ‘--list-installed’ is really about single lines that can be piped
to ‘cut’.  I’m not sure it’s the right place for what you have in mind.

> One step further: the record <manifest-entry> should be compliant with
> the option file '-f' or manifest '-m' of "guix package" (or "guix
> pack").
> Say, I created a profile, did some pulls, installed and removed
> packaged. Now I would like to easy "reproduce" this messy
> computational environment to another machine. Say I copy
> '<profile>/manifest' to 'my-mess', then if I can run "guix package -p
> my-profile -m my-mess" (or "guix pack"), I would be happy. ;-)
> Or if some compliance of '<profile>/manifest' and the option '-m'  is
> not possible, perhaps a way to convert this <profile>/manifest into a
> '-m' manifest.
> Maybe, is it already possible? Re-instatiate the tools from a profile.
>
> What do you think?
> Does it make sense?

It does!  In theory, for every package that has a ‘provenance’ property,
we could arrange to generate code that refers to an inferior with the
appropriate commit and returns a <manifest>.

I suspect it could easily get messy and impractical: the generated code
could end up instantiating a whole bunch of inferiors for really no good
reason, and instantiating that manifest could be disappointingly slow
because of that.

It might be easier to generate code that approximates what the profile
contains, with a warning when we see that there are several different
‘provenance’ properties.

Ludo’.