https://guix.gnu.org/feeds/blog/user-interfaces.atomGNU Guix — Blog — User interfacesfeed author nameGNU Guixhttps://guix.gnu.org/themes/initial/img/icon.png2024-03-20T10:57:54Zhttps://guix.gnu.org/blog/2021/from-guix-environment-to-guix-shell//From ‘guix environment’ to ‘guix shell’Ludovic Courtès2021-10-26T15:00:00Z2021-10-26T15:00:00Z There are times when what looked like the right design choice some years
back comes out as an odd choice as time passes. The beloved guix environment
tool is having that fate. Its command-line interface has become
non-intuitive and annoying for the most common use cases. Since it
could not be changed without breaking compatibility in fundamental ways,
we devised a new command meant to progressively replace it; guix shell —that’s
the name we unimaginatively ended up with—has just landed after a
three-week review period , itself a
followup to discussions and hesitations on the…<p>There are times when what looked like the right design choice some years
back comes out as an odd choice as time passes. The beloved <a href="https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-environment.html"><code>guix environment</code></a>
tool is having that fate. Its command-line interface has become
non-intuitive and annoying for the most common use cases. Since it
could not be changed without breaking compatibility in fundamental ways,
we devised a new command meant to progressively replace it; <a href="https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html"><code>guix shell</code></a>—that’s
the name we unimaginatively ended up with—has just landed after <a href="https://issues.guix.gnu.org/50960">a
three-week review period</a>, itself a
followup to discussions and hesitations on the best course of action.</p><p>This post introduces <code>guix shell</code>, how it differs from <code>guix environment</code>, the choices we made, and why we hope you will like it.</p><h1>The story of <code>guix environment</code></h1><p>The <code>guix environment</code> command <a href="https://lists.gnu.org/archive/html/guix-devel/2014-10/msg00111.html">started its life in
2014</a>,
when Guix was a two-year old baby and the whole community could fit in a
small room. It had one purpose: “to assist hackers in creating
reproducible development environments”. It was meant to be similar in
spirit to <a href="https://docs.python.org/3/tutorial/venv.html">VirtualEnv</a> or
<a href="https://bundler.io/">Bundler</a>, but <em>universal</em>—not limited to a single
language. You would run:</p><pre><code>guix environment inkscape</code></pre><p>… and obtain an interactive shell with all the packages needed to hack
on Inkscape; in that shell, the relevant environment variables—<code>PATH</code>,
<code>CPATH</code>, <code>PKG_CONFIG_PATH</code>, and so on—would automatically point to a
profile created on the fly and containing the compiler, libraries, and
tools Inkscape depends on, but not Inkscape itself.</p><p>Only a year later did it become clear that there are cases where one
would want to create an environment containing specific packages, rather
than an environment containing <em>the dependencies</em> of packages. To
address that, David Thompson <a href="https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00561.html">proposed the <code>--ad-hoc</code>
option</a>:</p><pre><code>guix environment --ad-hoc inkscape -- inkscape</code></pre><p>… would create an environment containing only Inkscape, and would then
launch the <code>inkscape</code> command in that environment. Many features were
added over the years, such as <a href="https://guix.gnu.org/en/blog/2015/container-provisioning-with-guix/">the invaluable <code>--container</code>
option</a>,
but these two modes, development and “ad hoc”, are the guts of it.</p><p>Fast forward six years: today, there’s consensus that the name
<code>--ad-hoc</code> is confusing for newcomers and above all, that the “ad hoc”
mode should be the default. This is the main problem that <a href="https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-environment.html"><code>guix shell</code></a>
addresses.</p><h1>Doing what you’d expect</h1><p>Changing the default mode from “development environment” to “ad hoc” is
technically easy, but how to do that without breaking compatibility is
harder. This led to <a href="https://issues.guix.gnu.org/38529">lengthy
discussions</a>, including proposals of
mechanisms to choose between the new and old semantics.</p><p>In the end, keeping the <code>guix environment</code> name while allowing it to
have different semantics was deemed dangerous. For one thing, there’s
lots of material out there that demoes <code>guix environment</code>—blog posts,
magazine articles, on-line courses—and it would have been impossible to
determine whether they refer to the “new” or to the “old” semantics. We
<a href="https://issues.guix.gnu.org/38529#17">reached the conclusion</a> that it
would be easier to use a new command name and to eventually deprecate
<code>guix environment</code>.</p><p>With <code>guix shell</code>, the default is to create an environment that contains
the packages that appear on the command line; to launch Inkscape, run:</p><pre><code>guix shell inkscape -- inkscape</code></pre><p>The <code>--ad-hoc</code> option is gone! Likewise, to spawn an ephemeral
development environment containing Python and a couple of libraries,
run:</p><pre><code>guix shell python python-numpy python-scipy -- python3</code></pre><p>Now, if you want, say, the development environment of Inkscape, add the
<code>--development</code> or <code>-D</code> option right before:</p><pre><code>guix shell -D inkscape</code></pre><p>You can add Git and GDB on top of it like so:</p><pre><code>guix shell -D inkscape git gdb</code></pre><p>(Note that <code>-D</code> only applies to the immediately following package,
<code>inkscape</code> in this case.) It’s more concise and more natural than with
<code>guix environment</code>. As can be seen <a href="https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html">in the
manual</a>,
all the other options supported by <code>guix environment</code> remain available
in <code>guix shell</code>.</p><h1>Short-hands for development environments</h1><p>A convention that’s become quite common is for developers to provide a
<code>guix.scm</code> at the top of their project source tree, so that others can
start a development environment right away:</p><pre><code>guix environment -l guix.scm</code></pre><p>The <code>guix.scm</code> file would contain a <a href="https://guix.gnu.org/manual/devel/en/html_node/Defining-Packages.html">package
definition</a>
for the project at hand, <a href="https://notabug.org/cwebber/guile-gcrypt/src/master/guix.scm">as in this
example</a>.
This option is known as <code>-f</code> in <code>guix shell</code>, for consistency with other
commands, and the equivalent command is:</p><pre><code>guix shell -D -f guix.scm</code></pre><p>Since all Guix commands accept a
<a href="https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html#index-manifest">“manifest”</a>
with <code>-m</code>, another option is to provide a <code>manifest.scm</code> file and to
run:</p><pre><code>guix shell -m manifest.scm</code></pre><p>“Wouldn’t it be nice if <code>guix shell</code> would automatically follow these
conventions when not given any argument?”, some
<a href="https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html">suggested</a>.
As in the case of Bundler, <a href="https://direnv.net/">direnv</a>, or typical
build tools from Meson to Make, having a default file name can save
typing and contribute to a good user experience for frequently-used
commands. In this spirit, <code>guix shell</code> automatically loads <code>guix.scm</code>
or <code>manifest.scm</code>, from the current directory or an ancestor thereof,
such that entering a project to hack on it is as simple as:</p><pre><code>cd ~/my/project/src
guix shell</code></pre><p>Worry not: <code>guix shell</code> loads <code>guix.scm</code> or <code>manifest.scm</code> <em>if and only
if</em> you have first added its directory to
<code>~/.config/guix/shell-authorized-directories</code>. Otherwise <code>guix shell</code>
warns you and prints a hint that you can copy/paste if you want to
authorize the directory.</p><h1>Caching environments</h1><p>With that in place, <code>guix shell</code> can pretty much fill the same role as
direnv and similar tools, with one difference though: speed. When all
the packages are already in store, <code>guix shell</code> can take one to a few
seconds to run, depending on the package set, on whether you’re using a
solid state device (SSD) or a “spinning” hard disk, and so on. It’s
acceptable but prohibitively slow for direnv-like use cases.</p><p>To address that, <code>guix shell</code> maintains a profile cache for the <code>-D -f guix.scm</code> and <code>-m manifest.scm</code> cases. On a hot cache, it runs in
0.1 second. All it has to do is fork a shell with the right environment
variable definitions; it does not talk to <code>guix-daemon</code>, and it does not
even read <code>guix.scm</code> or <code>manifest.scm</code> (it’s possible to forcefully
update the cache with <code>--rebuild-cache</code>).</p><p>That makes <code>guix shell</code> usable even for short-lived commands like
<code>make</code>:</p><pre><code>guix shell -- make</code></pre><p>Hopefully it’ll change the way we use the tool!</p><h1>The shell doctor</h1><p>While revamping this command-line interface, the idea of a “shell
doctor” came up. In interactive use, <code>guix shell</code> sets environment
variables and spawns a shell, but it’s not uncommon for the shell to
mess up with the whole environment. Why? Because, <a href="https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html">contrary to
documented
practice</a>,
it’s quite common for users to define or override environment variables
in the startup files of non-login shells, <code>~/.bashrc</code> for Bash,
<code>~/.zshrc</code> for Zsh. Instead, environment variable definitions should go
to the startup file of <em>login</em> shells—<code>~/.bash_profile</code>, <code>~/.profile</code>,
or similar. But let’s face it: it’s a subtle distinction that few of us
know or care about.</p><p>As a result, users of Guix, especially on distros other than Guix
System, would often be disappointed when running <code>guix environment --pure</code> and <em>yet</em> find that <code>PATH</code> contains non-Guix entries, that
there’s a bogus <code>LD_LIBRARY_PATH</code> definition, and whatnot. Now, they
can call the doctor, so to speak, to obtain a diagnosis of the health of
their shell by adding the <code>--check</code> flag:</p><pre><code>guix shell --check python python-numpy</code></pre><p>The command creates an environment containing Python and NumPy, spawns
an interactive shell, checks the environment variables as seen by the
shell, and prints a warning if <code>PATH</code> or <code>PYTHONPATH</code> in this case have
been overridden. It does not tell users where the problem comes from—it
cannot guess—but it tells them if something’s wrong, which is a first
step.</p><p>Of course, the best way to sidestep these problems is to pass
<code>--container</code>, which gives a fresh, isolated environment that does not
contain those startup files. That’s not always an option though, for
instance on systems lacking support for unprivileged user namespaces, so
<code>--check</code> comes in handy there.</p><h1>Try it!</h1><p>Just run <code>guix pull</code> to get this shiny new <code>guix shell</code> thingie!</p><p>If you don’t feel ready yet, that’s OK: <code>guix environment</code> won’t
disappear overnight. We have a <a href="https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-environment.html">written
commitment</a>
to keep it around until May, 1st 2023. Though overall, we hope you’ll
find the <code>guix shell</code> interface easier to use and compelling enough that
you’ll be willing to switch overnight!</p><h4>About GNU Guix</h4><p><a href="https://guix.gnu.org">GNU Guix</a> is a transactional package manager and
an advanced distribution of the GNU system that <a href="https://www.gnu.org/distros/free-system-distribution-guidelines.html">respects user
freedom</a>.
Guix can be used on top of any system running the Hurd or the Linux
kernel, or it can be used as a standalone operating system distribution
for i686, x86_64, ARMv7, AArch64 and POWER9 machines.</p><p>In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection. When used as a standalone
GNU/Linux distribution, Guix offers a declarative, stateless approach to
operating system configuration management. Guix is highly customizable
and hackable through <a href="https://www.gnu.org/software/guile">Guile</a>
programming interfaces and extensions to the
<a href="http://schemers.org">Scheme</a> language.</p>https://guix.gnu.org/blog/2019/guix-profiles-in-practice//Guix Profiles in PracticePierre Neidhardt2019-10-25T12:15:00Z2019-10-25T12:15:00Z Note: An updated version of this article is available in the brand new cookbook . Guix provides a very useful feature that may be quite foreign to newcomers:
profiles . They are a way to group package installations together and all users
on the same system are free to use as many profiles as they want. Whether you're a developer or not, you may find that multiple profiles bring you
great power and flexibility. While they shift the paradigm somewhat compared to
traditional package managers , they are very convenient to use once…<p><em>Note: An updated version of this article is available in the brand new <a href="https://guix.gnu.org/cookbook/en/">cookbook</a>.</em></p><p>Guix provides a very useful feature that may be quite foreign to newcomers:
<em>profiles</em>. They are a way to group package installations together and all users
on the same system are free to use as many profiles as they want.</p><p>Whether you're a developer or not, you may find that multiple profiles bring you
great power and flexibility. While they shift the paradigm somewhat compared to
<em>traditional package managers</em>, they are very convenient to use once you've
understood how to set them up.</p><p>If you are familiar with Python's <code>virtualenv</code>, you can think of a profile as a
kind of universal <code>virtualenv</code> that can hold any kind of software whatsoever, not
just Python software. Furthermore, profiles are self-sufficient: they capture
all the runtime dependencies which guarantees that all programs within a profile
will always work at any point in time.</p><p>Multiple profiles have many benefits:</p><ul><li><p>Clean semantic separation of the various packages a user needs for different contexts.</p></li><li><p>Multiple profiles can be made available into the environment either on login
or within a dedicated shell.</p></li><li><p>Profiles can be loaded on demand. For instance, the user can use multiple
shells, each of them running different profiles.</p></li><li><p>Isolation: Programs from one profile will not use programs from the other, and
the user can even install different versions of the same programs to the two
profiles without conflict.</p></li><li><p>Deduplication: Profiles share dependencies that happens to be the exact same.
This makes multiple profiles storage-efficient.</p></li><li><p>Reproducible: when used with declarative manifests, a profile can be fully
specified by the Guix commit that was active when it was set up. This means
that the exact same profile can be <a href="https://guix.gnu.org/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/">set up anywhere, anytime</a>, with just the
commit information. See section “Reproducible profiles” below.</p></li><li><p>Easier upgrades and maintenance: Multiple profiles make it easy to keep
package listings at hand and make upgrades completely friction-less.</p></li></ul><p>Concretely, here follows some typical profiles:</p><ul><li><p>The dependencies of a project you are working on.</p></li><li><p>Your favourite programming language libraries.</p></li><li><p>Laptop-specific programs (like <code>powertop</code>) that you don't need on a desktop.</p></li><li><p>TeXlive (this one can be really useful when you need to install just one
package for this one document you've just received over email).</p></li><li><p>Games.</p></li></ul><p>Let's dive in the set up!</p><h1>Basic setup with manifests</h1><p>A Guix profile can be set up <em>via</em> a so-called <em>manifest specification</em> that looks like
this:</p><pre><code class="language-scheme">(specifications->manifest
'("package-1"
;; Version 1.3 of package-2.
"package-2@1.3"
;; The "lib" output of package-3.
"package-3:lib"
; ...
"package-N"))</code></pre><p>See <a href="https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html">(guix) Invoking guix package</a> for the syntax details.</p><p>We can create a manifest specification per profile and install them this way:</p><pre><code>GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
mkdir -p "$GUIX_EXTRA_PROFILES"/my-project # if it does not exist yet
guix package --manifest=/path/to/guix-my-project-manifest.scm --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project</code></pre><p>Here we set an arbitrary variable <code>GUIX_EXTRA_PROFILES</code> to point to the directory
where we will store our profiles in the rest of this article.</p><p>Placing all your profiles in a single directory, with each profile getting its
own sub-directory, is somewhat cleaner. This way, each sub-directory will
contain all the symlinks for precisely one profile. Besides, "looping over
profiles" becomes obvious from any programming language (e.g. a shell script) by
simply looping over the sub-directories of <code>$GUIX_EXTRA_PROFILES</code>.</p><p>Note that it's also possible to loop over the output of</p><pre><code>guix package --list-profiles</code></pre><p>although you'll probably have to filter out <code>~/.config/guix/current</code>.</p><p>To enable all profiles on login, add this to your <code>~/.bash_profile</code> (or similar):</p><pre><code>for i in $GUIX_EXTRA_PROFILES/*; do
profile=$i/$(basename "$i")
if [ -f "$profile"/etc/profile ]; then
GUIX_PROFILE="$profile"
. "$GUIX_PROFILE"/etc/profile
fi
unset profile
done</code></pre><p>Note to Guix System users: the above reflects how your default profile
<code>~/.guix-profile</code> is activated from <code>/etc/profile</code>, that latter being loaded by
<code>~/.bashrc</code> by default.</p><p>You can obviously choose to only enable a subset of them:</p><pre><code>for i in "$GUIX_EXTRA_PROFILES"/my-project-1 "$GUIX_EXTRA_PROFILES"/my-project-2; do
profile=$i/$(basename "$i")
if [ -f "$profile"/etc/profile ]; then
GUIX_PROFILE="$profile"
. "$GUIX_PROFILE"/etc/profile
fi
unset profile
done</code></pre><p>When a profile is off, it's straightforward to enable it for an individual shell
without "polluting" the rest of the user session:</p><pre><code>GUIX_PROFILE="path/to/my-project" ; . "$GUIX_PROFILE"/etc/profile</code></pre><p>The key to enabling a profile is to <em>source</em> its <code>etc/profile</code> file. This file
contains shell code that exports the right environment variables necessary to
activate the software contained in the profile. It is built automatically by
Guix and meant to be sourced.
It contains the same variables you would get if you ran:</p><pre><code>guix package --search-paths=prefix --profile=$my_profile"</code></pre><p>Once again, see <a href="https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html">(guix) Invoking guix package</a> for the command line options.</p><p>To upgrade a profile, simply install the manifest again:</p><pre><code>guix package -m /path/to/guix-my-project-manifest.scm -p "$GUIX_EXTRA_PROFILES"/my-project/my-project</code></pre><p>To upgrade all profiles, it's easy enough to loop over them. For instance,
assuming your manifest specifications are stored in
<code>~/.guix-manifests/guix-$profile-manifest.scm</code>, with <code>$profile</code> being the name
of the profile (e.g. "project1"), you could do the following in Bourne shell:</p><pre><code>for profile in "$GUIX_EXTRA_PROFILES"/*; do
guix package --profile="$profile" --manifest="$HOME/.guix-manifests/guix-$profile-manifest.scm"
done</code></pre><p>Each profile has its own generations:</p><pre><code>guix package -p "$GUIX_EXTRA_PROFILES"/my-project/my-project --list-generations</code></pre><p>You can roll-back to any generation of a given profile:</p><pre><code>guix package -p "$GUIX_EXTRA_PROFILES"/my-project/my-project --switch-generations=17</code></pre><h1>Required packages</h1><p>Activating a profile essentially boils down to exporting a bunch of
environmental variables. This is the role of the <code>etc/profile</code> within the
profile.</p><p><em>Note: Only the environmental variables of the packages that consume them will
be set.</em></p><p>For instance, <code>MANPATH</code> won't be set if there is no consumer application for man
pages within the profile. So if you need to transparently access man pages once
the profile is loaded, you've got two options:</p><ul><li><p>Either export the variable manually, e.g.</p><pre><code>export MANPATH=/path/to/profile${MANPATH:+:}$MANPATH</code></pre></li><li><p>Or include <code>man-db</code> to the profile manifest.</p></li></ul><p>The same is true for <code>INFOPATH</code> (you can install <code>info-reader</code>),
<code>PKG_CONFIG_PATH</code> (install <code>pkg-config</code>), etc.</p><h1>Default profile</h1><p>What about the default profile that Guix keeps in <code>~/.guix-profile</code>?</p><p>You can assign it the role you want. Typically you would install the manifest
of the packages you want to use all the time.</p><p>Alternatively, you could keep it "manifest-less" for throw-away packages
that you would just use for a couple of days.
This way makes it convenient to run</p><pre><code>guix install package-foo
guix upgrade package-bar</code></pre><p>without having to specify the path to a profile.</p><h1>The benefits of manifests</h1><p>Manifests are a convenient way to keep your package lists around and, say,
to synchronize them across multiple machines using a version control system.</p><p>A common complaint about manifests is that they can be slow to install when they
contain large number of packages. This is especially cumbersome when you just
want get an upgrade for one package within a big manifest.</p><p>This is one more reason to use multiple profiles, which happen to be just
perfect to break down manifests into multiple sets of semantically connected
packages. Using multiple, small profiles provides more flexibility and
usability.</p><p>Manifests come with multiple benefits. In particular, they ease maintenance:</p><ul><li><p>When a profile is set up from a manifest, the manifest itself is
self-sufficient to keep a "package listing" around and reinstall the profile
later or on a different system. For ad-hoc profiles, we would need to
generate a manifest specification manually and maintain the package versions
for the packages that don't use the default version.</p></li><li><p><code>guix package --upgrade</code> always tries to update the packages that have
propagated inputs, even if there is nothing to do. Guix manifests remove this
problem.</p></li><li><p>When partially upgrading a profile, conflicts may arise (due to diverging
dependencies between the updated and the non-updated packages) and they can be
annoying to resolve manually. Manifests remove this problem altogether since
all packages are always upgraded at once.</p></li><li><p>As mentioned above, manifests allow for reproducible profiles, while the
imperative <code>guix install</code>, <code>guix upgrade</code>, etc. do not, since they produce
different profiles every time even when they hold the same packages. See
<a href="https://issues.guix.gnu.org/issue/33285">the related discussion on the matter</a>.</p></li><li><p>Manifest specifications are usable by other <code>guix</code> commands. For example, you
can run <code>guix weather -m manifest.scm</code> to see how many substitutes are
available, which can help you decide whether you want to try upgrading today
or wait a while. Another example: you can run <code>guix pack -m manifest.scm</code> to
create a pack containing all the packages in the manifest (and their
transitive references).</p></li><li><p>Finally, manifests have a Scheme representation, the <code><manifest></code> record type.
They can be manipulated in Scheme and passed to the various Guix <a href="https://en.wikipedia.org/wiki/Api">APIs</a>.</p></li></ul><p>It's important to understand that while manifests can be used to declare
profiles, they are not strictly equivalent: profiles have the side effect that
they "pin" packages in the store, which prevents them from being
<a href="https://guix.gnu.org/manual/en/html_node/Invoking-guix-gc.html">garbage-collected</a> and ensures that they will still be available at any point in
the future.</p><p>Let's take an example:</p><ol><li><p>We have an environment for hacking on a project for which there isn't a Guix
package yet. We build the environment using a manifest, and then run <code>guix environment -m manifest.scm</code>. So far so good.</p></li><li><p>Many weeks pass and we have run a couple of <code>guix pull</code> in the mean time.
Maybe a dependency from our manifest has been updated; or we may have run
<code>guix gc</code> and some packages needed by our manifest have been
garbage-collected.</p></li><li><p>Eventually, we set to work on that project again, so we run <code>guix environment -m manifest.scm</code>. But now we have to wait for Guix to build and install
stuff!</p></li></ol><p>Ideally, we could spare the rebuild time. And indeed we can, all we need is to
install the manifest to a profile and use <code>GUIX_PROFILE=/the/profile; . "$GUIX_PROFILE"/etc/profile</code> as explained above: this guarantees that our
hacking environment will be available at all times.</p><p><em>Security warning:</em> While keeping old profiles around can be convenient, keep in
mind that outdated packages may not have received the latest security fixes.</p><h1>Reproducible profiles</h1><p>To reproduce a profile bit-for-bit, we need two pieces of information:</p><ul><li>a manifest,</li><li>a Guix channel specification.</li></ul><p>Indeed, manifests alone might not be enough: different Guix versions (or
different channels) can produce different outputs for a given manifest.</p><p>You can output the Guix channel specification with <code>guix describe --format=channels</code>.
Save this to a file, say <code>channel-specs.scm</code>.</p><p>On another computer, you can use the channel specification file and the manifest
to reproduce the exact same profile:</p><pre><code>GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
GUIX_EXTRA=$HOME/.guix-extra
mkdir "$GUIX_EXTRA"/my-project
guix pull --channels=channel-specs.scm --profile "$GUIX_EXTRA/my-project/guix"
mkdir -p "$GUIX_EXTRA_PROFILES/my-project"
"$GUIX_EXTRA"/my-project/guix/bin/guix package --manifest=/path/to/guix-my-project-manifest.scm --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project</code></pre><p>It's safe to delete the Guix channel profile you've just installed with the
channel specification, the project profile does not depend on it.</p><h1>Special thanks</h1><p>Chris Marusich and Simon Tournier for their thorough feedback.</p><h1>About GNU Guix</h1><p><a href="https://www.gnu.org/software/guix">GNU Guix</a> is a transactional package manager and an advanced distribution of the
GNU system that <a href="https://www.gnu.org/distros/free-system-distribution-guidelines.html">respects user freedom</a>. Guix can be used on top of any system
running the kernel Linux, or it can be used as a standalone operating system
distribution for i686, x86_64, ARMv7, and AArch64 machines.</p><p>In addition to standard package management features, Guix supports transactional
upgrades and roll-backs, unprivileged package management, per-user profiles, and
garbage collection. When used as a standalone GNU/Linux distribution, Guix
offers a declarative, stateless approach to operating system configuration
management. Guix is highly customizable and hackable through <a href="https://www.gnu.org/software/guile">Guile</a> programming
interfaces and extensions to the <a href="http://schemers.org/">Scheme</a> language.</p>https://guix.gnu.org/blog/2014/guix-at-the-2014-gnu-hackers-meeting//Guix at the 2014 GNU Hackers MeetingLudovic Courtès2014-10-11T00:00:00+02002014-10-11T00:00:00+0200 The Guix talk of this summer's GNU Hackers Meeting is now available (get the slides ). DOWNLOAD VIDEO (WebM, 60 minutes) It gives an introduction to Guix from a user's viewpoint, and covers topics such as features for GNU maintainers, programming interfaces, declarative operating system configuration, status of the GNU/Hurd port, and the new Emacs and Web interfaces---with a bunch of demos. Do not miss other fine talks from the GHM . Many thanks to everyone who took care of the video recordings. …<p>The Guix talk of this summer's GNU Hackers Meeting is now available (get the <a href="https://www.gnu.org/software/guix/guix-ghm-20140815.pdf">slides</a>).</p><video src="https://audio-video.gnu.org/video/ghm2014/2014-08--courtes--were-building-the-gnu-system--ghm.webm" controls="controls"><div class="action-box centered-text"><a class="button-big" href="https://audio-video.gnu.org/video/ghm2014/2014-08--courtes--were-building-the-gnu-system--ghm.webm">DOWNLOAD VIDEO</a><p>(WebM, 60 minutes)</p></div></video><p>It gives an introduction to Guix from a user's viewpoint, and covers topics such as features for GNU maintainers, programming interfaces, declarative operating system configuration, status of the GNU/Hurd port, and the new Emacs and Web interfaces---with a bunch of demos.</p><p>Do not miss <a href="http://audio-video.gnu.org/video/ghm2014/">other fine talks from the GHM</a>. Many thanks to everyone who took care of the video recordings.</p>https://guix.gnu.org/blog/2014/emacs-as-a-general-purpose-package-manager//Emacs as a general-purpose package managerLudovic Courtès2014-09-04T00:00:00+02002014-09-04T00:00:00+0200 GNU Guix , the package manager written for the GNU system, now has a neat Emacs user interface! It offers a visual, user-friendly alternative to the guix package command-line interface . For those familiar with package.el , the main user interface is quite similar: commands like guix-newest-available-packages, guix-search-by-regexp, and guix-installed-packages present a browsable list of packages. Individual packages can be selected, which displays additional details and presents a button to install or delete them. It is also possible to mark a set of packages for installation, upgrade, or deletion,…<div><p><a href="http://www.gnu.org/software/guix">GNU Guix</a>, the package manager written for the GNU system, now has a neat Emacs user interface! It offers a visual, user-friendly alternative to the guix package <a href="http://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-package.html">command-line interface</a>.<br /></p><p>For those familiar with <a href="http://www.gnu.org/software/emacs/manual/en/html_node/emacs/Packages.html">package.el</a>, the main user interface is quite similar: commands like guix-newest-available-packages, guix-search-by-regexp, and guix-installed-packages present a browsable list of packages. Individual packages can be selected, which displays additional details and presents a button to install or delete them. It is also possible to mark a set of packages for installation, upgrade, or deletion, and execute the set of operations in a single transaction.<br /></p><p>The interface has been developed by Alex Kost and was merged in Guix a day ago. It uses <a href="http://nongnu.org/geiser/">Geiser</a>, the beloved Guile/Emacs interface and development environment, to communicate with the underlying Guile process. That Guile process, in turn, simply uses Guix and <a href="http://www.gnu.org/software/guix/manual/en/html_node/Package-Modules.html">the whole distribution</a> as libraries—the goodness of embedding the <a href="http://www.gnu.org/software/guix/manual/en/html_node/Defining-Packages.html">packaging DSL</a> in a general-purpose language.<br /></p><p>Try it out and <a href="http://www.gnu.org/software/guix/#contact">let us know</a> what you think!<br /></p></div>