1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
|
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<title>GNU Guix, package manager, system distribution and more</title>
<link rel="stylesheet" href="css/reveal.css">
<link rel="stylesheet" href="css/theme/black.css">
<style>
.reveal h1 {
text-transform: unset;
}
.reveal h2 {
text-transform: unset;
}
.reveal h3 {
text-transform: unset;
}
img {
background: none !important;
border: none !important;
box-shadow: none !important;
}
pre {
background: none !important;
border: none !important;
box-shadow: none !important;
}
.caption {
display: block;
clear: both;
font-size: large !important;
}
</style>
<!-- Theme used for syntax highlighting of code -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
</head>
<body>
<div class="reveal">
<div class="slides">
<section>
<img src="Guix.svg" style="background: unset; margin: unset; border: unset; box-shadow: unset;">
<h1>GNU Guix</h1>
<h2>Package manager,<br> system distribution<br> and more…</h2>
<aside class="notes" data-markdown>
Hello, my name is Chris, and I'm talking about package
management with GNU Guix.
I first found out about Guix sometime in late 2015, early
2016.
I remember installing it the night before FOSDEM back in
2016 and I started using and contributing to Guix soon
after.
</section>
<section>
<h2>Dependable</h2>
<h2>Flexible</h2>
<h2>General Purpose</h2>
<aside class="notes" data-markdown>
Some of the concepts involved in Guix take a bit of
getting used to, so I've tried to break down the benefits
and properties in to 3 areas.
Dependability, flexibility, and Guix's position as a
general purpose package manager.
</aside>
</section>
<section>
<h1>Dependable</h1>
<p>The immutable store is a rock solid base to build on</p>
<p>Package behaviour can be fixed at build time</p>
<p>You can rollback changes</p>
<aside class="notes" data-markdown>
Starting with dependability, I consider Guix to be a very
dependable package manager.
The main building block for dependability is a immutable
store, a directory where data can be added, but not
changed. With Guix, the location for this is somewhat
fixed, at /gnu/store.
When you build packages with Guix, you can build them in
such a way that the behaviour will be fixed at build
time. I'll give some concrete examples of this later on.
The other part of dependability is handling problems that
inevitably arise. Sometimes things go wrong with software,
and the ideal first step is to just back out the change
you just made. The architecture that Guix uses supports
this elegantly.
</aside>
</section>
<section>
<h1>Flexible</h1>
<p>Use prebuilt packages, or build from source</p>
<p>Tweak package definitions, and add your own</p>
<p>No conflicts between different packages</p>
<aside class="notes" data-markdown>
Having spent a couple of years now doing a few odd things
with Guix, I can say for sure that it's really flexible.
Guix supports downloading binaries from elsewhere to
install, but also building those same packages from
source, and that can come in really useful if you start
tweaking package definitions or adding your own.
Guix also elegantly supports handling multiple versions of
the same bit of software at once, or even multiple
different packages of the same version of the same bit of
software, built with different arguments say.
</aside>
</section>
<section>
<h1>General purpose</h1>
<p>Advancement through diversity</p>
<p>No barriers of programming language or field of use</p>
<p>Leverage Guix wherever you need it</p>
<p>Works on multiple distributions and architectures</p>
<aside class="notes" data-markdown>
Finally, Guix is a general purpose package
manager. Personally, this is something I have a big
preference for. I think the problems of package management
are best tackled without fracturing the effort along lines
like programming languages, or fields of use.
While Guix is a general purpose package manager, it also
has specific tooling, for example if you want to generate
Docker images, you can pack up some Guix packages in to a
Docker image with ease.
Guix as a package manager works on many systems, including
GuixSD, a system based around Guix. This means that it
sits across that historical divide between package
managers for operating systems, and other package
managers.
</aside>
</section>
<section>
<pre style="font-size: 1.2em; text-align: center;">
$ guix package --install hello
</pre>
<pre class="fragment" style="font-size: 1.2em; text-align: center;">
$ hello
Hello, world!
</pre>
<aside class="notes" data-markdown>
On to the practical bit now, lets take a look at a few
examples of using Guix packages.
You might be able to guess what running this command does.
It will look at the available packages, find one called
hello, and then install it to the current users profile.
In case you haven't encountered hello, it's purpose is
pretty simple. It provides a binary called hello that
prints out hello world when you run it.
</aside>
</section>
<section data-transition="fade-out">
<pre> </pre>
<img class="stretch noborder" src="profile-0.svg">
<a href="https://git.sv.gnu.org/cgit/guix/maintenance.git/tree/talks/bobkonf2017/profile-0.svg"
class="caption">
Modified, © Ricardo Wurmus
</a>
<aside class="notes" data-markdown>
The really key bit with this method of using Guix packages
is the profiles.
Let's take another example. Here you can see the default
layout for a users default profile. In this case they have
two packages installed, samtools and bowtie.
You'd usually expect to:
- have a .guix-profile symlink in your home directory
- that points to another symlink somewhere in /var/guix
- which points to another symlink which is named with a
number
This number is the generation of the profile. The
generation symlink then points to a directory in the
store.
It is that directory in the store where the profile is
stored, and while it will contain files, these files will
be symlinks to other items in the store.
All of this complexity is normally hidden, as a user, you
just source the /etc/profile file within the profile, and
then all the environment variables you need will be
set. In this case, the PATH environment variable will be
set so that you can run samtools and bowtie2.
</aside>
</section>
<section data-transition="fade">
<pre>guix package -r bowtie</pre>
<img class="stretch noborder" src="profile-1.svg">
<a href="https://git.sv.gnu.org/cgit/guix/maintenance.git/tree/talks/bobkonf2017/profile-1.svg"
class="caption">
Modified, © Ricardo Wurmus
</a>
<aside class="notes" data-markdown>
Things get interesting when you make a change. Say you
remove the bowtie package.
A new generation of your profile will be generated,
pointing to a new profile in the store, now not containing
bowtie, and just containing samtools.
The guix-profile symlink in /var/guix has been updated to
point at this new generation.
Going back to dependability, something important has
happened here, or rather not happened.
The bowtie package it still in the store, and the 42nd
generation of the profile is as well. Nothing in the store
has been deleted. This means that you can roll back to the
previous generation by changing one symlink.
</aside>
</section>
<section data-transition="fade-in">
<pre>guix package --roll-back</pre>
<img class="stretch noborder" src="rollback.svg">
<a href="https://git.sv.gnu.org/cgit/guix/maintenance.git/tree/talks/bobkonf2017/rollback.svg"
class="caption">
Modified, © Ricardo Wurmus
</a>
<aside class="notes" data-markdown>
The roll back can be done by running the guix package
command with the --roll-back flag.
Let's just flip through that so you can see the changes.
To recap, the immutable nature of the store, and the
ability to roll back profiles makes Guix very dependable.
</aside>
</section>
<section>
<h3>Development environment for hello</h3>
<br>
<pre style="font-size: 0.8em;">$ guix environment hello</pre>
<pre style="font-size: 0.8em;" class="fragment">$ type -p gcc
/gnu/store/32812c4rxsprnyifhbv21pd6d796r1w8-profile/bin/gcc</pre>
<aside class="notes" data-markdown>
On to some flexibility now.
The guix package command deals with profiles, but the guix
environment command does as well.
The purpose of this command is to create development
environments, without having to install the packages
through the guix package command. It's pretty flexible
itself though!
Just running this command will drop you in to a subshell
using a new profile created to contain the packages you'd
need to build the hello package, for example, things like
gcc will be on the path.
</aside>
</section>
<section>
<code>
guix environment --ad-hoc hello guile
</code>
<br><br>
<pre class="fragment">/gnu/store/5w8jk6p57l5an1d39lngw560r2bw2dx1-profile/bin
├── guild -> /gnu/store/yih…6fk-guile-2.2.2/bin/guild
├── guile -> /gnu/store/yih…6fk-guile-2.2.2/bin/guile
├── guile-config -> /gnu/store/yih…6fk-guile-2.2.2/bin/guile-config
├── guile-snarf -> /gnu/store/yih…6fk-guile-2.2.2/bin/guile-snarf
├── guile-tools -> /gnu/store/yih…6fk-guile-2.2.2/bin/guile-tools
└── hello -> /gnu/store/wf6…2sx-hello-2.10/bin/hello</pre>
<aside class="notes" data-markdown>
Looking past the purpose of the guix environment command,
in general it offers a really flexible way of generating
arbitrary profiles.
Here is how you generate a profile containing the hello
and guile packages.
(Next)
If you were to look at the profile in the store, you'd see
something like this. The bin directory of the profile
contains symlinks to the bin directories of the hello and
guile packages.
This is how profiles compose multiple packages together.
</aside>
</section>
<section>
<h2>Recap</h2>
<p>Install to your users profile:
<pre style="text-align: center;">$ guix package -i ...</pre>
</p>
<p>Enter a development environment:
<pre style="text-align: center;">$ guix environment ...</pre>
</p>
<p>Enter a environment with specific packages:
<pre style="text-align: center;">$ guix environment --ad-hoc ...</pre>
</p>
<aside class="notes" data-markdown>
Let's recap quickly.
We've looked at two commands, guix package and guix
environment.
Both work with packages and profiles, but in slightly
different ways.
Let's now take a look at some more interesting ways of
using Guix packages.
</aside>
</section>
<section>
<pre style="font-size: 0.7em; text-align: center;">
$ guix environment --container --ad-hoc hello
</pre>
<br>
<pre class="fragment">$ echo /gnu/store/*
/gnu/store/…-ncurses-6.0 /gnu/store/…-profile
/gnu/store/…-manual-database /gnu/store/…-gcc-5.4.0-lib
/gnu/store/…-info-dir /gnu/store/…-bash-4.4.12
/gnu/store/…-readline-7.0 /gnu/store/…-glibc-2.25
/gnu/store/…-hello-2.10 /gnu/store/…-bash-static-4.4.12</pre>
<aside class="notes" data-markdown>
Usually, Guix packages explicitly rely on their
dependencies by pointing at them with absolute paths to
those items in the store.
This is really useful for reliability, as the store is
immutable, this means that dependencies used in this way
won't change.
It also provides for some flexibility, as you know what's
needed, you can remove everything else.
This is what this command does. It's similar to the last
guix environment command, but with --container.
Now the bash shell is started with an isolated view of the
system, for example it's in a different process namespace,
and different mount namespace with only access to the
parts of the store that are required, the current
directory, and some key parts of the root file system.
(Next)
If you run this command, and then look in the store,
you'll see only what is needed to run bash and hello.
Note that here I'm talking about containers just in terms
of the sense of Linux namespaces. Not really anything
else. Somehow the term "containers" has got dragged in to
issues around managing state and software packages, but in
this case, the architecture of Guix allows for some clear
separation between the two concepts.
</aside>
</section>
<section data-background="white">
<img src="hello-references-graph.svg">
<pre>guix graph --type=references hello</pre>
<aside class="notes" data-markdown>
Now this is only possible as Guix can find all the
necessary store items for all the things you want in the
container. Sometimes this is called a closure.
This is a graph generated with Guix for the references for
the hello package.
This was generated with the guix graph command, and this
command and others like guix size can be really useful
when digging in to the packages and understanding the
graph.
</aside>
</section>
<section>
<small><pre>$ ldd /gnu/store/wf65hjwqwpz4wllasn63zysi5irql2sx-hello-2.10/bin/hello
linux-vdso.so.1 (0x00007ffece166000)
libgcc_s.so.1 => /gnu/store/3x53yv4v144c9xp02rs64z7j597kkqax-gcc-5.4.0-lib/lib/libgcc_s.so.1 (0x00007fee83076000)
libc.so.6 => /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/libc.so.6 (0x00007fee82cd7000)
/gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/ld-linux-x86-64.so.2 (0x00007fee8328d000)</pre></small>
<aside class="notes" data-markdown>
Back to some more dependability now.
What does it mean that the hello package references the
glibc package?
Well in this case, one of the references is in the
libraries used by the hello binary.
hello is linking against the libc shared library with an
absolute path.
This gives you shared libraries, rather than static
linking, which can help with space issues, but as the
store is immutable you get similar dependability to static
linking.
This is a concrete example of fixing the behavior of a
package at build time. If you were linking against a libc
shared library which could change, then maybe this could
affect the hello package.
</aside>
</section>
<section>
<pre>
guix package -i hello --profile=test-profile
</pre>
<pre>
$ ls -l test-profile*
... test-profile -> test-profile-1-link
... test-profile-1-link ->
/gnu/store/7pyxcs7yh7xbl3lbjdf5g6z0b4kl7pzf-profile
</pre>
<aside class="notes" data-markdown>
Back to some flexibility, maybe having one profile per
user isn't enough.
This isn't a problem, as the guix package command can use
and create different profiles.
Here the profile is called test-profile, and what that
means is Guix creates some symlinks to manage that profile
in the current directory.
</aside>
</section>
<section>
<h2>Guix + Direnv</h2>
<br><br>
<code>
use guix --ad-hoc gcc-toolchain python python-lxml
</code>
<br><br>
<code>
<pre>$ cd /tmp/foo
direnv: loading .envrc
direnv: using guix --ad-hoc gcc-toolchain python python-lxml
direnv: export +PAGER +PYTHONPATH ~CPLUS_INCLUDE_PATH
~C_INCLUDE_PATH ~LIBRARY_PATH ~PATH</pre>
</code>
<aside class="notes" data-markdown>
This is a neat way that I use guix environment, and hook
it up with another program called direnv.
direnv is an environment switcher for the shell, and guix
environment can specify environment variables to load a
profile. Therefore, you can combine the two so that when
you enter a directory, direnv will invoke guix to load the
environment.
Direnv is configured through using a file named .envrc in
the directory you want it to be active in.
The example I'm showing here is to create an environment
containing gcc-toolchain, python and python-lxml when you
enter the /tmp/foo directory.
</aside>
</section>
<section>
<h1><pre>guix pack</pre></h1>
<p>
The guix pack command creates a shrink-wrapped pack or
software bundle.
</p>
<aside class="notes" data-markdown>
The guix pack command can be really practical. Offering a
way to get some of the benefits of using Guix, but also
some of the benefits of binary bundles of software.
</aside>
</section>
<section>
<pre>$ guix pack guile emacs geiser
...
...
/gnu/store/v5dq15c61k0gb5w8w9psgszd56vnca0v-tarball-pack.tar.gz</pre>
<aside class="notes" data-markdown>
Here, packing up guile emacs and geiser will give you a
tarball containing those store items, but also all of
their direct and indirect dependencies.
</aside>
</section>
<section>
<pre>$ guix pack -f docker guile emacs geiser
...
...
/gnu/store/mym3ipc9v0ki9y9vijjmyqrsajc1y3sz-docker-pack.tar.gz</pre>
<aside class="notes" data-markdown>
Generating a tarball is the default, but the other format
currently available is docker.
</aside>
</section>
<section>
<h2>Writing a package definition</h2>
<p>
Importers available for: gnu, nix, pypi, cpan, hackage,
stackage, elpa, gem, cran, crate, texlive and json.
</p>
<aside class="notes" data-markdown>
Guix has definitions for around six and a half thousand
packages, but you might want to use something that is
missing. One thing you can do is look at packaging it!
Guix contains several importers, which can use existing
metadata from some source, to construct a package
definition.
Depending on the importer, and how complete the
information it had available was, you might be able to
build this package straight away, or it might need some
tweaking.
</aside>
</section>
<section>
<h2>Hello package definition</h2>
<small class="stretch"><pre>
<code class="scheme">(define-public hello
(package
(name "hello")
(version "2.10")
(source (origin
(method url-fetch)
(uri (string-append "mirror://gnu/hello/hello-" version
".tar.gz"))
(sha256
(base32
"0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
(build-system gnu-build-system)
(synopsis "Hello, GNU world: An example GNU package")
(description
"GNU Hello prints the message \"Hello, world!\" and then exits. It
serves as an example of standard GNU coding practices. As such, it supports
command-line arguments, multiple languages, and so on.")
(home-page "https://www.gnu.org/software/hello/")
(license gpl3+)))</code></pre></small>
<aside class="notes" data-markdown>
Here is an example package definition. This one is for the
hello package we looked at earlier.
This package definition is pretty simple, as the build
system takes care of the entire process. Guix is capable
of packaging complicated and difficult software though.
It's also pretty amazing to think about what that short
definition just shown represents.
One part of why Guix packages are so dependable is that
the definitions specify exactly what that package is,
including all its dependencies, referred to as inputs.
Often these inputs are packages themselves, plus maybe
some data, the source tarball in the case of hello. The
inputs for all the dependent packages are also exactly
specified.
</aside>
</section>
<section data-background-color="white">
<img class="noborder" src="hello-derivation-graph.svg">
<span class="caption">
Derivation graph for the hello package
</span>
<aside class="notes" data-markdown>
This means you can build up a graph like this, showing the
parts involved in the entire process of creating this
package.
Now I don't expect you to read this, but I have coloured
some of the nodes differently. The black ones are the
fixed bits of data, where the hash is known in advance.
The purple ones are the derivations, that maybe take some
data, and some outputs from other derivations and generate
some outputs themselves.
The hello package is just one of these purple coloured
nodes.
Now you might have noticed earlier that the store items
contain a random looking string of characters.
For the black nodes in this graph, this hash roughly
corresponds to the data itself.
For the purple nodes in the graph, the hash represents the
process that is represented by that node.
As hello is at the top of this directed acyclic graph,
that means if any of the data represented by the black
nodes changes, or any of the derivations represented by
the purple nodes changes, you'll get a different hello
package, a different item in the store.
</aside>
</section>
<section>
<h3>Talk to others on</h3>
<h2>#guix on freenode</h2>
<p>
For the manual, mailing lists, papers, blog posts and
talks, go to
<a href="https://gnu.org/s/guix/help">
https://gnu.org/s/guix/help
</a>
</p>
<aside class="notes" data-markdown>
Thank you for listening, I hope you've enjoyed this very
quick look at package management with Guix.
If you'd like to talk to others, there is an active IRC
channel, #guix on Freenode.
From the website, you can find a online version of the
manual, and details on the mailing lists.
Tomorrow, there are also a couple of talks involving Guix
in the high performance computing track. Including a talk
by Ludovic Courtès, the creator of the Guix project.
</alias>
</section>
</div>
</div>
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.js"></script>
<script>
// More info about config & dependencies:
// - https://github.com/hakimel/reveal.js#configuration
// - https://github.com/hakimel/reveal.js#dependencies
Reveal.initialize({
controls: false,
history: true,
showNotes: true,
dependencies: [
{ src: 'plugin/markdown/marked.js' },
{ src: 'plugin/markdown/markdown.js' },
{ src: 'plugin/notes/notes.js', async: true },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
{ src: 'plugin/tagcloud/tagcloud.js', async: true }
]
});
</script>
</body>
</html>
|