Hi Guix!
l...@gnu.org (Ludovic Courtès) skribis:
> • Have a “channel” mechanism, similar to ‘nix-channel’, that would
> allow users to have several Guix variants available in parallel
> instead of just “latest”. Could work like this:
>
> guix channel add latest git://git.sv.gnu.org/guix.git master
> guix channel add stable git://git.sv.gnu.org/guix.git stable
> guix channel pull latest
> guix channel set latest
> # here i see the latest versions of everything
> guix channel set stable
> # and here everything is old but super stable ;-)
The patches that follow implement this last bit, though in a slightly
different way. Users would now have the option to provide
~/.config/guix/channels.scm along these lines:
(cons (channel
(name 'guix-hpc)
(url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git";)
(branch "origin/master"))
%default-channels)
‘guix pull’ then pulls both from ‘%default-channels’, a one-element list
containing our Savannah repo, and from that ‘guix-hpc’ repo. It builds
both Guix itself and the modules in ‘guix-hpc’, with a dependency on the
just-built Guix. The ~/.config/guix/current profile then contains two
entries:
--8<---------------cut here---------------start------------->8---
$ guix pull -l
[…]
Generacio 18 Aug 27 2018 09:54:40
guix 1ca5499
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: origin/master
commit: 1ca54999db34b0197e6c7fa3f0a852fc0d193e70
10 new packages: avogadro, emacs-git-annex, find-circ, guile-aa-tree,
lepton-eda, r-a3,
r-abcanalysis, r-manipulatewidget, r-miniui, r-slam
43 packages upgraded: byobu@5.127, cpupower@4.18.5, darcs@2.14.1,
drumkv1@0.9.2, duplicity@0.7.18,
emacs-recent-addresses@0.1-1.afbbfdc, font-gnu-unifont@11.0.02,
freefall@4.18.5, gdb-arm-none-eabi@8.1.1,
gdb@8.1.1, ghc-integer-logarithms@1.0.2.1,
ghc-optparse-applicative@0.14.2.0, ghc-quickcheck-instances@0.3.18,
ghc-scientific@0.3.6.2, ghc-smallcheck@1.1.5, ghc-zlib@0.6.2,
guile-lib@0.2.6.1, guile2.0-lib@0.2.6.1,
guile2.2-lib@0.2.6.1, keepassxc@2.3.4, libgig@4.1.0, libx11@1.6.6,
linux-libre-arm-generic@4.18.5,
linux-libre-arm-omap2plus@4.18.5, linux-libre@4.18.5, ncmpc@0.29,
openssh@7.8p1, padthv1@0.9.2,
parallel@20180822, perf@4.18.5, qjackctl@0.5.3, r-car@3.0-1,
r-catools@1.17.1.1, r-devtools@1.13.6,
r-digest@0.6.16, r-dplyr@0.7.6, r-rcpp@0.12.18, r-synchronicity@1.3.5,
r-trimcluster@0.1-2.1, samplv1@0.9.2,
synthv1@0.9.2, tuxguitar@1.5.2, yubico-piv-tool@1.6.1
Generacio 19 Aug 27 2018 16:20:48
guix d894ab8
repository URL: file:///home/ludo/src/guix
branch: origin/wip-channels
commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
guix-hpc dd3df5e
repository URL: file:///home/ludo/src/guix-hpc
branch: origin/wip-channel-test
commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb
11 new packages: chameleon, eztrace, fxt, litl, maphys, pastix, simgrid,
starpu, starpu,
starpu-fxt, starpu-simgrid
4 packages upgraded: capstone@3.0.5-rc2, emacs-racket-mode@0.0.2-2.1b78827,
python-capstone@3.0.5-rc2, python2-capstone@3.0.5-rc2
--8<---------------cut here---------------end--------------->8---
GUIX_PACKAGE_PATH is no longer needed (though it’s still supported):
~/.config/guix/current/bin/guix automatically finds packages defined in
the ‘guix-hpc’ channel.
The only missing bit for this patch series is documentation for channels
(including a prominent disclaimer about API compatibility). I’ll write
it if people agree with the overall approach.
Implementation
~~~~~~~~~~~~~~
(guix channels) implements the “channel” and “channel instance”
abstractions. It provides tools to get the latest instance of channel
and to build a list of instances. There must always be a channel called
‘guix’, which all other instances depend on.
(guix scripts pull) now does little more than implementing the CLI,
while (guix channels) does all the heavy lifting.
Limitations
~~~~~~~~~~~
Currently third-party channels are expected to provide nothing but
package modules. Those package modules should live at the root of the
repository; for example, the modules/ directory at
https://gitlab.inria.fr/guix-hpc/guix-hpc doesn’t work, you have to
“git mv modules/inria .” for things to work.
Both limitations could be lifted by honoring a special meta-data file in
repositories. But I think that can come later.
Third-party channels currently all implicitly depend on the ‘guix’
channel, but it’s not possible to express dependencies among channels.
It may be useful, but it can probably come later, too.
If a channel fails to build, the user gets a backtrace and it’s up to
them to figure out what to do. May need to be improved. :-)
Not really a limitation, but (guix describe) relies on argv[0] to find
channel meta-data. I’m not a fan of that but it works in practice.
More importantly, it’s the only way I could think of to retrieve
“silent” meta-data (repo URL, commit, etc.) as well as channel
directories where packages should be searched for.
Future work
~~~~~~~~~~~
With (guix channels) we’ll be able to implement things like “open an
inferior corresponding to commit X”. In turn, that means we can support
commit IDs in manifests, and then “guix package -m manifest.scm” will
open an inferior for the requested commit ID and instantiate the thing.
With (guix describe) we can, of course, implement a ‘guix describe’
command. We can also improve provenance tracking, for instance by
storing as a manifest entry property the channel instance an installed
package comes from.
Thoughts? Ricardo?
Thanks in advance for your feedback!
Ludo’.
