Pinning a Guix version

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • zimoun
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
wishlist
L
L
Ludovic Courtès wrote on 26 Nov 2015 14:30
(address . bug-guix@gnu.org)
87egfcyjjk.fsf@gnu.org
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’.
L
L
L
Ludovic Courtès wrote on 12 Feb 2016 15:17
control message for bug #22017
(address . control@debbugs.gnu.org)
87y4aqypwj.fsf@gnu.org
severity 22017 wishlist
Z
Z
zimoun wrote on 27 Nov 2019 18:06
Bug #22017 Hunting: Pinning a Guix version
CAJ3okZ0n6r3XFf+AGVkQbQQf-xqqaG_M9ae4Jq=vW8MsDyvGVA@mail.gmail.com
Hi Ludo,

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



You wrote:

Toggle snippet (5 lines)
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.


However, you wrote:

Toggle snippet (5 lines)
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.

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:

Toggle snippet (4 lines)
See <http://permalink.gmane.org/gmane.linux.distributions.nixos/18703>
for a good source of inspiration!

which is now broken. )-:



Cheers,
simon
L
L
Ludovic Courtès wrote on 28 Nov 2019 09:34
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 22017@debbugs.gnu.org)
87blswz9fk.fsf@gnu.org
Hello!

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

Toggle quote (14 lines)
> 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!

Toggle quote (11 lines)
> 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’.
Z
Z
zimoun wrote on 28 Nov 2019 11:53
(address . 22017-done@debbugs.gnu.org)
CAJ3okZ31NYK6PR5zUcQxXH8TDapjwVTzRk67LFw-wnSBMTF+ew@mail.gmail.com
On Thu, 28 Nov 2019 at 09:34, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (3 lines)
> Yes, I think we should close this issue and create a new one about
> tagging Guix revisions/channel instances.

done. :-)
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 22017@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 22017
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch