GNU bug report logs -
#22017
Pinning a Guix version
Previous Next
Reported by: ludo <at> gnu.org (Ludovic Courtès)
Date: Thu, 26 Nov 2015 13:32:02 UTC
Severity: wishlist
Done: zimoun <zimon.toutoune <at> gmail.com>
Bug is archived. No further changes may be made.
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.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#22017
; Package
guix
.
(Thu, 26 Nov 2015 13:32:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
ludo <at> gnu.org (Ludovic Courtès)
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Thu, 26 Nov 2015 13:32:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#22017
; Package
guix
.
(Thu, 26 Nov 2015 14:05:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 22017 <at> debbugs.gnu.org (full text, mbox):
See <http://permalink.gmane.org/gmane.linux.distributions.nixos/18703>
for a good source of inspiration!
Ludo’.
Severity set to 'wishlist' from 'normal'
Request was from
ludo <at> gnu.org (Ludovic Courtès)
to
control <at> debbugs.gnu.org
.
(Fri, 12 Feb 2016 14:18:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#22017
; Package
guix
.
(Wed, 27 Nov 2019 17:08:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 22017 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#22017
; Package
guix
.
(Thu, 28 Nov 2019 08:35:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 22017 <at> debbugs.gnu.org (full text, mbox):
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’.
Reply sent
to
zimoun <zimon.toutoune <at> gmail.com>
:
You have taken responsibility.
(Thu, 28 Nov 2019 10:54:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
ludo <at> gnu.org (Ludovic Courtès)
:
bug acknowledged by developer.
(Thu, 28 Nov 2019 10:54:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 22017-done <at> debbugs.gnu.org (full text, mbox):
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. :-)
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 26 Dec 2019 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 114 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.