GNU bug report logs - #22017
Pinning a Guix version

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22017 in the body.
You can then email your comments to 22017 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guix <at> gnu.org
Subject: Pinning a Guix version
Date: Thu, 26 Nov 2015 14:30:55 +0100

Hello!

In some cases, it’s useful to be able to pin a particular Guix version
and to use that version (see the RepPar paper for some examples.)

A naive way to do that is:

  git clone …/guix.git my-pinned-guix
  (cd my-pinned-guix; git checkout deadbeef)
  guix package -L my-pinned-guix --manifest=my-manifest.scm

However, this is currently broken for several reasons:

  1. ‘fold-packages’ recursively traverses ‘my-pinned-guix’ for .scm
     files, and on its way it finds build-aux/build-self.scm,
     tests/*.scm, and emacs/*.scm, which breaks it all.  These
     directories have to be explicitly removed before we can do
     something.

     Internally, ‘%package-module-path’ can have entries that are pairs
     and where the cdr restricts the search of .scm files to a
     sub-directory.  We should expose that facility to -L and
     ‘GUIX_PACKAGE_PATH’ using some special syntax.

     That way, one could do (say):

       guix package -L my-pinned-guix,gnu/packages

     meaning that only the ‘gnu/packages’ sub-directory is searched.

     OTOH, it may be advisable to use the (guix …) modules from
     ‘my-pinned-guix’ and not just the (gnu packages …) modules, because
     the former obviously contribute to the final result.

  2. The ‘gnu/packages/patches’ sub-directory is not automatically added
     to the search path, so in fact one has to run:

       guix package -L my-pinned-guix \
         -L my-pinned-guix/gnu/packages/patches …
  
     so that patches are found.  Not convenient.

  3. When doing so, we get loads of:

     ;;; note: source file /tmp/guix/guix/build/perl-build-system.scm
     ;;;       newer than compiled /home/ludo/src/guix/guix/build/perl-build-system.go

     We should silence Guile.

  4. Related to #1: since everything is evaluated, this is ~10 times
     slower than the normal thing.

I think ‘guix pull’ would be a good place to add support for tagging
Guixes and similar, but it would be good if the naive approach above
would work just as well.

Ludo’.

Message #8 received at 22017 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: 22017 <at> debbugs.gnu.org
Subject: Re: bug#22017: Pinning a Guix version
Date: Thu, 26 Nov 2015 15:04:11 +0100

See <http://permalink.gmane.org/gmane.linux.distributions.nixos/18703>
for a good source of inspiration!

Ludo’.

Message #13 received at 22017 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: 22017 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Bug #22017 Hunting: Pinning a Guix version
Date: Wed, 27 Nov 2019 18:06:59 +0100

Hi Ludo,

The bug [1] describes a wishlist about pinning Guix version. I think
it is almost done.

[1] http://issues.guix.gnu.org/issue/22017


You wrote:

--8<---------------cut here---------------start------------->8---
  git clone …/guix.git my-pinned-guix
  (cd my-pinned-guix; git checkout deadbeef)
  guix package -L my-pinned-guix --manifest=my-manifest.scm
--8<---------------cut here---------------end--------------->8---

which is now possible with

  guix pull --commit=deadbeef
  guix package -m my-manifest.scm

Moreover, "guix time-machine" also handles such use case. If I understand well.


However, you wrote:

--8<---------------cut here---------------start------------->8---
I think ‘guix pull’ would be a good place to add support for tagging
Guixes and similar, but it would be good if the naive approach above
would work just as well.
--8<---------------cut here---------------end--------------->8---

and it is not currently supported, AFAIK.

Recently, a lot of new features have been discussed on guix-devel.
This one has not been raised: add local tags to ease the navigation
through different versions of Guix. It is not clear to me if it should
be under "guix pull", e.g., "guix pull --tag=add foo" or another
command "guix tag add foo".

Because it is an really old bug, I am not sure that this whishlist
will efficiently work as a reminder, so I am inclined to close it or
maybe change the title or raise this very tagging feature to
guix-devel.


What do you think?


Cheers,
simon

--

As source of inspiration, you provided this link:

--8<---------------cut here---------------start------------->8---
See <http://permalink.gmane.org/gmane.linux.distributions.nixos/18703>
for a good source of inspiration!
--8<---------------cut here---------------end--------------->8---

which is now broken. )-:



Cheers,
simon

Message #16 received at 22017 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 22017 <at> debbugs.gnu.org
Subject: Re: Bug #22017 Hunting: Pinning a Guix version
Date: Thu, 28 Nov 2019 09:34:07 +0100

Hello!

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

> You wrote:
>
>   git clone …/guix.git my-pinned-guix
>   (cd my-pinned-guix; git checkout deadbeef)
>   guix package -L my-pinned-guix --manifest=my-manifest.scm
>
>
> which is now possible with
>
>   guix pull --commit=deadbeef
>   guix package -m my-manifest.scm
>
> Moreover, "guix time-machine" also handles such use case. If I understand well.

Yes, pinning is definitely implemented, and much more nicely than what I
was suggesting back in 2015!

> Recently, a lot of new features have been discussed on guix-devel.
> This one has not been raised: add local tags to ease the navigation
> through different versions of Guix. It is not clear to me if it should
> be under "guix pull", e.g., "guix pull --tag=add foo" or another
> command "guix tag add foo".
>
> Because it is an really old bug, I am not sure that this whishlist
> will efficiently work as a reminder, so I am inclined to close it or
> maybe change the title or raise this very tagging feature to
> guix-devel.

Yes, I think we should close this issue and create a new one about
tagging Guix revisions/channel instances.

Thanks!

Ludo’.

Message #21 received at 22017-done <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: 22017-done <at> debbugs.gnu.org
Subject: Re: Bug #22017 Hunting: Pinning a Guix version
Date: Thu, 28 Nov 2019 11:53:40 +0100

On Thu, 28 Nov 2019 at 09:34, Ludovic Courtès <ludo <at> gnu.org> wrote:

> Yes, I think we should close this issue and create a new one about
> tagging Guix revisions/channel instances.

done. :-)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.