Newer
Older
@example
$ guix refresh
gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0
@end example
Alternately, one can specify packages to consider, in which case a
warning is emitted for packages that lack an updater:
@example
$ guix refresh coreutils guile guile-ssh
gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh
gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13
@end example
@command{guix refresh} browses the upstream repository of each package and determines
the highest version number of the releases therein. The command
knows how to update specific types of packages: GNU packages, ELPA
packages, etc.---see the documentation for @option{--type} below. There
are many packages, though, for which it lacks a method to determine
whether a new upstream release is available. However, the mechanism is
extensible, so feel free to get in touch with us to add a new method!
When passed @code{--update}, it modifies distribution source files to
update the version numbers and source tarball hashes of those package
recipes (@pxref{Defining Packages}). This is achieved by downloading
each package's latest source tarball and its associated OpenPGP
signature, authenticating the downloaded tarball against its signature
using @command{gpg}, and finally computing its hash. When the public
key used to sign the tarball is missing from the user's keyring, an
attempt is made to automatically retrieve it from a public key server;
when this is successful, the key is added to the user's keyring; otherwise,
@command{guix refresh} reports an error.
The following options are supported:
@table @code
@item --expression=@var{expr}
@itemx -e @var{expr}
Consider the package @var{expr} evaluates to.
This is useful to precisely refer to a package, as in this example:
@example
guix refresh -l -e '(@@@@ (gnu packages commencement) glibc-final)'
@end example
This command lists the dependents of the ``final'' libc (essentially all
the packages.)
Update distribution source files (package recipes) in place. This is
usually run from a checkout of the Guix source tree (@pxref{Running
Guix Before It Is Installed}):
@example
$ ./pre-inst-env guix refresh -s non-core -u
@xref{Defining Packages}, for more information on package definitions.
@item --select=[@var{subset}]
@itemx -s @var{subset}
Select all the packages in @var{subset}, one of @code{core} or
@code{non-core}.
The @code{core} subset refers to all the packages at the core of the
distribution---i.e., packages that are used to build ``everything
else''. This includes GCC, libc, Binutils, Bash, etc. Usually,
changing one of these packages in the distribution entails a rebuild of
all the others. Thus, such updates are an inconvenience to users in
terms of build time or bandwidth used to achieve the upgrade.
The @code{non-core} subset refers to the remaining packages. It is
typically useful in cases where an update of the core packages would be
inconvenient.
@item --manifest=@var{file}
@itemx -m @var{file}
Select all the packages from the manifest in @var{file}. This is useful to
check if any packages of the user manifest can be updated.
@item --type=@var{updater}
@itemx -t @var{updater}
Select only packages handled by @var{updater} (may be a comma-separated
list of updaters). Currently, @var{updater} may be one of:
@table @code
@item gnu
the updater for GNU packages;
@item gnome
the updater for GNOME packages;
@item kde
the updater for KDE packages;
@item xorg
the updater for X.org packages;
@item kernel.org
the updater for packages hosted on kernel.org;
the updater for @uref{http://elpa.gnu.org/, ELPA} packages;
@item cran
the updater for @uref{http://cran.r-project.org/, CRAN} packages;
@item bioconductor
the updater for @uref{http://www.bioconductor.org/, Bioconductor} R packages;
@item cpan
the updater for @uref{http://www.cpan.org/, CPAN} packages;
the updater for @uref{https://pypi.python.org, PyPI} packages.
@item gem
the updater for @uref{https://rubygems.org, RubyGems} packages.
@item github
the updater for @uref{https://github.com, GitHub} packages.
@item hackage
the updater for @uref{https://hackage.haskell.org, Hackage} packages.
@item stackage
the updater for @uref{https://www.stackage.org, Stackage} packages.
@item crate
the updater for @uref{https://crates.io, Crates} packages.
For instance, the following command only checks for updates of Emacs
packages hosted at @code{elpa.gnu.org} and for updates of CRAN packages:
$ guix refresh --type=elpa,cran
gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9
@end example
@end table
In addition, @command{guix refresh} can be passed one or more package
names, as in this example:
@example
$ ./pre-inst-env guix refresh -u emacs idutils gcc@@4.8
@end example
@noindent
The command above specifically updates the @code{emacs} and
@code{idutils} packages. The @code{--select} option would have no
effect in this case.
When considering whether to upgrade a package, it is sometimes
convenient to know which packages would be affected by the upgrade and
should be checked for compatibility. For this the following option may
be used when passing @command{guix refresh} one or more package names:
@table @code
@item --list-updaters
@itemx -L
List available updaters and exit (see @option{--type} above.)
For each updater, display the fraction of packages it covers; at the
end, display the fraction of packages covered by all these updaters.
@item --list-dependent
@itemx -l
List top-level dependent packages that would need to be rebuilt as a
result of upgrading one or more packages.
@xref{Invoking guix graph, the @code{reverse-package} type of
@command{guix graph}}, for information on how to visualize the list of
dependents of a package.
@end table
Be aware that the @code{--list-dependent} option only
@emph{approximates} the rebuilds that would be required as a result of
an upgrade. More rebuilds might be required under some circumstances.
@example
$ guix refresh --list-dependent flex
Building the following 120 packages would ensure 213 dependent packages are rebuilt:
hop@@2.4.0 geiser@@0.4 notmuch@@0.18 mu@@0.9.9.5 cflow@@1.4 idutils@@4.6 @dots{}
@end example
The command above lists a set of packages that could be built to check
for compatibility with an upgraded @code{flex} package.
The following options can be used to customize GnuPG operation:
@table @code
@item --gpg=@var{command}
Use @var{command} as the GnuPG 2.x command. @var{command} is searched
for in @code{$PATH}.
@item --key-download=@var{policy}
Handle missing OpenPGP keys according to @var{policy}, which may be one
of:
@table @code
@item always
Always download missing OpenPGP keys from the key server, and add them
to the user's GnuPG keyring.
@item never
Never try to download missing OpenPGP keys. Instead just bail out.
@item interactive
When a package signed with an unknown OpenPGP key is encountered, ask
the user whether to download it or not. This is the default behavior.
@end table
@item --key-server=@var{host}
Use @var{host} as the OpenPGP key server when importing a public key.
The @code{github} updater uses the
@uref{https://developer.github.com/v3/, GitHub API} to query for new
releases. When used repeatedly e.g. when refreshing all packages,
GitHub will eventually refuse to answer any further API requests. By
default 60 API requests per hour are allowed, and a full refresh on all
GitHub packages in Guix requires more than this. Authentication with
GitHub through the use of an API token alleviates these limits. To use
an API token, set the environment variable @code{GUIX_GITHUB_TOKEN} to a
token procured from @uref{https://github.com/settings/tokens} or
otherwise.
@node Invoking guix lint
@section Invoking @command{guix lint}
@cindex @command{guix lint}
@cindex package, checking for errors
The @command{guix lint} command is meant to help package developers avoid
common errors and use a consistent style. It runs a number of checks on
a given set of packages in order to find common mistakes in their
definitions. Available @dfn{checkers} include (see
@code{--list-checkers} for a complete list):
@table @code
@item synopsis
@itemx description
Validate certain typographical and stylistic rules about package
descriptions and synopses.
@item inputs-should-be-native
Identify inputs that should most likely be native inputs.
@item source
@itemx home-page
@itemx source-file-name
Probe @code{home-page} and @code{source} URLs and report those that are
invalid. Suggest a @code{mirror://} URL when applicable. Check that
the source file name is meaningful, e.g. is not
just a version number or ``git-checkout'', without a declared
@code{file-name} (@pxref{origin Reference}).
@cindex security vulnerabilities
@cindex CVE, Common Vulnerabilities and Exposures
Report known vulnerabilities found in the Common Vulnerabilities and
Exposures (CVE) databases of the current and past year
@uref{https://nvd.nist.gov/download.cfm#CVE_FEED, published by the US
NIST}.
To view information about a particular vulnerability, visit pages such as:
@itemize
@item
@indicateurl{https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-YYYY-ABCD}
@item
@indicateurl{https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-ABCD}
@end itemize
@noindent
where @code{CVE-YYYY-ABCD} is the CVE identifier---e.g.,
@code{CVE-2015-7554}.
Package developers can specify in package recipes the
@uref{https://nvd.nist.gov/cpe.cfm,Common Platform Enumeration (CPE)}
name and version of the package when they differ from the name that Guix
uses, as in this example:
@example
(package
(name "grub")
;; @dots{}
;; CPE calls this package "grub2".
(properties '((cpe-name . "grub2"))))
@end example
@item formatting
Warn about obvious source code formatting issues: trailing white space,
use of tabulations, etc.
The general syntax is:
@example
guix lint @var{options} @var{package}@dots{}
@end example
If no package is given on the command line, then all packages are checked.
The @var{options} may be zero or more of the following:
@table @code
@item --list-checkers
@itemx -l
List and describe all the available checkers that will be run on packages
and exit.
@item --checkers
@itemx -c
Only enable the checkers specified in a comma-separated list using the
names returned by @code{--list-checkers}.
@node Invoking guix size
@section Invoking @command{guix size}
@cindex size
@cindex package size
@cindex closure
@cindex @command{guix size}
The @command{guix size} command helps package developers profile the
disk usage of packages. It is easy to overlook the impact of an
additional dependency added to a package, or the impact of using a
single output for a package that could easily be split (@pxref{Packages
with Multiple Outputs}). Such are the typical issues that
The command can be passed a package specification such as @code{gcc@@4.8}
6332
6333
6334
6335
6336
6337
6338
6339
6340
6341
6342
6343
6344
6345
6346
6347
6348
6349
6350
6351
6352
6353
6354
or @code{guile:debug}, or a file name in the store. Consider this
example:
@example
$ guix size coreutils
store item total self
/gnu/store/@dots{}-coreutils-8.23 70.0 13.9 19.8%
/gnu/store/@dots{}-gmp-6.0.0a 55.3 2.5 3.6%
/gnu/store/@dots{}-acl-2.2.52 53.7 0.5 0.7%
/gnu/store/@dots{}-attr-2.4.46 53.2 0.3 0.5%
/gnu/store/@dots{}-gcc-4.8.4-lib 52.9 15.7 22.4%
/gnu/store/@dots{}-glibc-2.21 37.2 37.2 53.1%
@end example
@cindex closure
The store items listed here constitute the @dfn{transitive closure} of
Coreutils---i.e., Coreutils and all its dependencies, recursively---as
would be returned by:
@example
$ guix gc -R /gnu/store/@dots{}-coreutils-8.23
@end example
Here the output shows three columns next to store items. The first column,
labeled ``total'', shows the size in mebibytes (MiB) of the closure of
the store item---that is, its own size plus the size of all its
dependencies. The next column, labeled ``self'', shows the size of the
item itself. The last column shows the ratio of the size of the item
itself to the space occupied by all the items listed here.
In this example, we see that the closure of Coreutils weighs in at
70@tie{}MiB, half of which is taken by libc. (That libc represents a
large fraction of the closure is not a problem @i{per se} because it is
always available on the system anyway.)
When the package passed to @command{guix size} is available in the
store, @command{guix size} queries the daemon to determine its
dependencies, and measures its size in the store, similar to @command{du
-ms --apparent-size} (@pxref{du invocation,,, coreutils, GNU
Coreutils}).
When the given package is @emph{not} in the store, @command{guix size}
reports information based on the available substitutes
(@pxref{Substitutes}). This makes it possible it to profile disk usage of
store items that are not even on disk, only available remotely.
You can also specify several package names:
@example
$ guix size coreutils grep sed bash
store item total self
/gnu/store/@dots{}-coreutils-8.24 77.8 13.8 13.4%
/gnu/store/@dots{}-grep-2.22 73.1 0.8 0.8%
/gnu/store/@dots{}-bash-4.3.42 72.3 4.7 4.6%
/gnu/store/@dots{}-readline-6.3 67.6 1.2 1.2%
@dots{}
total: 102.3 MiB
@end example
@noindent
In this example we see that the combination of the four packages takes
102.3@tie{}MiB in total, which is much less than the sum of each closure
since they have a lot of dependencies in common.
@item --substitute-urls=@var{urls}
Use substitute information from @var{urls}.
@xref{client-substitute-urls, the same option for @code{guix build}}.
@item --sort=@var{key}
Sort lines according to @var{key}, one of the following options:
@table @code
@item self
the size of each item (the default);
@item closure
the total size of the item's closure.
Write a graphical map of disk usage in PNG format to @var{file}.
For the example above, the map looks like this:
@image{images/coreutils-size-map,5in,, map of Coreutils disk usage
produced by @command{guix size}}
This option requires that
@uref{http://wingolog.org/software/guile-charting/, Guile-Charting} be
installed and visible in Guile's module search path. When that is not
the case, @command{guix size} fails as it tries to load it.
@item --system=@var{system}
@itemx -s @var{system}
Consider packages for @var{system}---e.g., @code{x86_64-linux}.
@end table
@node Invoking guix graph
@section Invoking @command{guix graph}
@cindex DAG
@cindex @command{guix graph}
@cindex package dependencies
Packages and their dependencies form a @dfn{graph}, specifically a
directed acyclic graph (DAG). It can quickly become difficult to have a
mental model of the package DAG, so the @command{guix graph} command
provides a visual representation of the DAG. By default,
@command{guix graph} emits a DAG representation in the input format of
@uref{http://www.graphviz.org/, Graphviz}, so its output can be passed
directly to the @command{dot} command of Graphviz. It can also emit an
HTML page with embedded JavaScript code to display a ``chord diagram''
in a Web browser, using the @uref{https://d3js.org/, d3.js} library, or
emit Cypher queries to construct a graph in a graph database supporting
the @uref{http://www.opencypher.org/, openCypher} query language.
The general syntax is:
@example
guix graph @var{options} @var{package}@dots{}
@end example
For example, the following command generates a PDF file representing the
package DAG for the GNU@tie{}Core Utilities, showing its build-time
dependencies:
@example
guix graph coreutils | dot -Tpdf > dag.pdf
@end example
The output looks like this:
@image{images/coreutils-graph,2in,,Dependency graph of the GNU Coreutils}
Nice little graph, no?
But there is more than one graph! The one above is concise: it is the
graph of package objects, omitting implicit inputs such as GCC, libc,
grep, etc. It is often useful to have such a concise graph, but
sometimes one may want to see more details. @command{guix graph} supports
several types of graphs, allowing you to choose the level of detail:
This is the default type used in the example above. It shows the DAG of
package objects, excluding implicit dependencies. It is concise, but
filters out many details.
@item reverse-package
This shows the @emph{reverse} DAG of packages. For example:
@example
guix graph --type=reverse-package ocaml
@end example
... yields the graph of packages that depend on OCaml.
Note that for core packages this can yield huge graphs. If all you want
is to know the number of packages that depend on a given package, use
@command{guix refresh --list-dependent} (@pxref{Invoking guix refresh,
@option{--list-dependent}}).
@item bag-emerged
This is the package DAG, @emph{including} implicit inputs.
For instance, the following command:
@example
guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf
@end example
... yields this bigger graph:
@image{images/coreutils-bag-graph,,5in,Detailed dependency graph of the GNU Coreutils}
At the bottom of the graph, we see all the implicit inputs of
@var{gnu-build-system} (@pxref{Build Systems, @code{gnu-build-system}}).
Now, note that the dependencies of these implicit inputs---that is, the
@dfn{bootstrap dependencies} (@pxref{Bootstrapping})---are not shown
here, for conciseness.
@item bag
Similar to @code{bag-emerged}, but this time including all the bootstrap
dependencies.
@item bag-with-origins
Similar to @code{bag}, but also showing origins and their dependencies.
@item derivations
This is the most detailed representation: It shows the DAG of
derivations (@pxref{Derivations}) and plain store items. Compared to
the above representation, many additional nodes are visible, including
For this type of graph, it is also possible to pass a @file{.drv} file
name instead of a package name, as in:
@example
guix graph -t derivation `guix system build -d my-config.scm`
@end example
All the types above correspond to @emph{build-time dependencies}. The
following graph type represents the @emph{run-time dependencies}:
@table @code
@item references
This is the graph of @dfn{references} of a package output, as returned
by @command{guix gc --references} (@pxref{Invoking guix gc}).
If the given package output is not available in the store, @command{guix
graph} attempts to obtain dependency information from substitutes.
Here you can also pass a store file name instead of a package name. For
example, the command below produces the reference graph of your profile
(which can be big!):
@example
guix graph -t references `readlink -f ~/.guix-profile`
@end example
@item referrers
This is the graph of the @dfn{referrers} of a store item, as returned by
@command{guix gc --referrers} (@pxref{Invoking guix gc}).
This relies exclusively on local information from your store. For
instance, let us suppose that the current Inkscape is available in 10
profiles on your machine; @command{guix graph -t referrers inkscape}
will show a graph rooted at Inkscape and with those 10 profiles linked
to it.
It can help determine what is preventing a store item from being garbage
collected.
@end table
The available options are the following:
@table @option
@item --type=@var{type}
@itemx -t @var{type}
Produce a graph output of @var{type}, where @var{type} must be one of
the values listed above.
@item --list-types
List the supported graph types.
@item --backend=@var{backend}
@itemx -b @var{backend}
Produce a graph using the selected @var{backend}.
@item --list-backends
List the supported graph backends.
Currently, the available backends are Graphviz and d3.js.
@item --expression=@var{expr}
@itemx -e @var{expr}
Consider the package @var{expr} evaluates to.
This is useful to precisely refer to a package, as in this example:
@example
guix graph -e '(@@@@ (gnu packages commencement) gnu-make-final)'
@end example
@node Invoking guix environment
@section Invoking @command{guix environment}
@cindex reproducible build environments
@cindex development environments
@cindex @command{guix environment}
@cindex environment, package build environment
The purpose of @command{guix environment} is to assist hackers in
creating reproducible development environments without polluting their
package profile. The @command{guix environment} tool takes one or more
packages, builds all of their inputs, and creates a shell
environment to use them.
The general syntax is:
@example
guix environment @var{options} @var{package}@dots{}
@end example
The following example spawns a new shell set up for the development of
GNU@tie{}Guile:
@example
guix environment guile
@end example
If the needed dependencies are not built yet, @command{guix environment}
automatically builds them. The environment of the new shell is an augmented
version of the environment that @command{guix environment} was run in.
It contains the necessary search paths for building the given package
added to the existing environment variables. To create a ``pure''
environment, in which the original environment variables have been unset,
use the @code{--pure} option@footnote{Users sometimes wrongfully augment
environment variables such as @code{PATH} in their @file{~/.bashrc}
file. As a consequence, when @code{guix environment} launches it, Bash
may read @file{~/.bashrc}, thereby introducing ``impurities'' in these
environment variables. It is an error to define such environment
variables in @file{.bashrc}; instead, they should be defined in
@file{.bash_profile}, which is sourced only by log-in shells.
@xref{Bash Startup Files,,, bash, The GNU Bash Reference Manual}, for
details on Bash start-up files.}.
@vindex GUIX_ENVIRONMENT
@command{guix environment} defines the @code{GUIX_ENVIRONMENT}
variable in the shell it spawns; its value is the file name of the
profile of this environment. This allows users to, say, define a
specific prompt for development environments in their @file{.bashrc}
(@pxref{Bash Startup Files,,, bash, The GNU Bash Reference Manual}):
@example
if [ -n "$GUIX_ENVIRONMENT" ]
then
export PS1="\u@@\h \w [dev]\$ "
fi
@end example
@noindent
... or to browse the profile:
@example
$ ls "$GUIX_ENVIRONMENT/bin"
@end example
Additionally, more than one package may be specified, in which case the
union of the inputs for the given packages are used. For example, the
command below spawns a shell where all of the dependencies of both Guile
and Emacs are available:
@example
guix environment guile emacs
@end example
Sometimes an interactive shell session is not desired. An arbitrary
command may be invoked by placing the @code{--} token to separate the
command from the rest of the arguments:
guix environment guile -- make -j4
In other situations, it is more convenient to specify the list of
packages needed in the environment. For example, the following command
runs @command{python} from an environment containing Python@tie{}2.7 and
NumPy:
@example
guix environment --ad-hoc python2-numpy python-2.7 -- python
Furthermore, one might want the dependencies of a package and also some
additional packages that are not build-time or runtime dependencies, but
are useful when developing nonetheless. Because of this, the
@code{--ad-hoc} flag is positional. Packages appearing before
@code{--ad-hoc} are interpreted as packages whose dependencies will be
added to the environment. Packages appearing after are interpreted as
packages that will be added to the environment directly. For example,
the following command creates a Guix development environment that
additionally includes Git and strace:
@example
guix environment guix --ad-hoc git strace
@end example
Sometimes it is desirable to isolate the environment as much as
possible, for maximal purity and reproducibility. In particular, when
using Guix on a host distro that is not GuixSD, it is desirable to
prevent access to @file{/usr/bin} and other system-wide resources from
the development environment. For example, the following command spawns
a Guile REPL in a ``container'' where only the store and the current
working directory are mounted:
@example
guix environment --ad-hoc --container guile -- guile
@end example
@quotation Note
The @code{--container} option requires Linux-libre 3.19 or newer.
@end quotation
The available options are summarized below.
@item --root=@var{file}
@itemx -r @var{file}
@cindex persistent environment
@cindex garbage collector root, for environments
Make @var{file} a symlink to the profile for this environment, and
register it as a garbage collector root.
This is useful if you want to protect your environment from garbage
collection, to make it ``persistent''.
When this option is omitted, the environment is protected from garbage
collection only for the duration of the @command{guix environment}
session. This means that next time you recreate the same environment,
you could have to rebuild or re-download packages.
@item --expression=@var{expr}
@itemx -e @var{expr}
Create an environment for the package or list of packages that
@var{expr} evaluates to.
For example, running:
@example
guix environment -e '(@@ (gnu packages maths) petsc-openmpi)'
@end example
starts a shell with the environment for this specific variant of the
PETSc package.
Running:
@example
@end example
starts a shell with all the GuixSD base packages available.
The above commands only use the default output of the given packages.
To select other outputs, two element tuples can be specified:
@example
guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'
@end example
@item --load=@var{file}
@itemx -l @var{file}
Create an environment for the package or list of packages that the code
within @var{file} evaluates to.
As an example, @var{file} might contain a definition like this
(@pxref{Defining Packages}):
@example
@verbatiminclude environment-gdb.scm
@end example
@item --ad-hoc
Include all specified packages in the resulting environment, as if an
@i{ad hoc} package were defined with them as inputs. This option is
useful for quickly creating an environment without having to write a
package expression to contain the desired inputs.
For instance, the command:
@example
guix environment --ad-hoc guile guile-sdl -- guile
@end example
runs @command{guile} in an environment where Guile and Guile-SDL are
available.
Note that this example implicitly asks for the default output of
@code{guile} and @code{guile-sdl}, but it is possible to ask for a
specific output---e.g., @code{glib:bin} asks for the @code{bin} output
of @code{glib} (@pxref{Packages with Multiple Outputs}).
This option may be composed with the default behavior of @command{guix
environment}. Packages appearing before @code{--ad-hoc} are interpreted
as packages whose dependencies will be added to the environment, the
default behavior. Packages appearing after are interpreted as packages
that will be added to the environment directly.
@item --pure
Unset existing environment variables when building the new environment.
This has the effect of creating an environment in which search paths
only contain package inputs.
@item --search-paths
Display the environment variable definitions that make up the
environment.
@item --system=@var{system}
@itemx -s @var{system}
Attempt to build for @var{system}---e.g., @code{i686-linux}.
@item --container
@itemx -C
@cindex container
Run @var{command} within an isolated container. The current working
directory outside the container is mapped inside the container.
Additionally, a dummy home directory is created that matches the current
user's home directory, and @file{/etc/passwd} is configured accordingly.
The spawned process runs as the current user outside the container, but
has root privileges in the context of the container.
@item --network
@itemx -N
For containers, share the network namespace with the host system.
Containers created without this flag only have access to the loopback
device.
@item --expose=@var{source}[=@var{target}]
For containers, expose the file system @var{source} from the host system
as the read-only file system @var{target} within the container. If
@var{target} is not specified, @var{source} is used as the target mount
point in the container.
The example below spawns a Guile REPL in a container in which the user's
home directory is accessible read-only via the @file{/exchange}
directory:
@example
guix environment --container --expose=$HOME=/exchange --ad-hoc guile -- guile
For containers, share the file system @var{source} from the host system
as the writable file system @var{target} within the container. If
@var{target} is not specified, @var{source} is used as the target mount
point in the container.
The example below spawns a Guile REPL in a container in which the user's
home directory is accessible for both reading and writing via the
@file{/exchange} directory:
@example
guix environment --container --share=$HOME=/exchange --ad-hoc guile -- guile
@command{guix environment}
also supports all of the common build options that @command{guix
build} supports (@pxref{Common Build Options}).
@node Invoking guix publish
@section Invoking @command{guix publish}
The purpose of @command{guix publish} is to enable users to easily share
their store with others, who can then use it as a substitute server
(@pxref{Substitutes}).
When @command{guix publish} runs, it spawns an HTTP server which allows
anyone with network access to obtain substitutes from it. This means
that any machine running Guix can also act as if it were a build farm,
since the HTTP interface is compatible with Hydra, the software behind
the @code{hydra.gnu.org} build farm.
For security, each substitute is signed, allowing recipients to check
their authenticity and integrity (@pxref{Substitutes}). Because
@command{guix publish} uses the signing key of the system, which is only
readable by the system administrator, it must be started as root; the
@code{--user} option makes it drop root privileges early on.
The signing key pair must be generated before @command{guix publish} is
launched, using @command{guix archive --generate-key} (@pxref{Invoking
guix archive}).
The general syntax is:
@example
guix publish @var{options}@dots{}
@end example
Running @command{guix publish} without any additional arguments will
spawn an HTTP server on port 8080:
@example
guix publish
@end example
Once a publishing server has been authorized (@pxref{Invoking guix
archive}), the daemon may download substitutes from it:
@example
guix-daemon --substitute-urls=http://example.org:8080
@end example
By default, @command{guix publish} compresses archives on the fly as it
serves them. This ``on-the-fly'' mode is convenient in that it requires
no setup and is immediately available. However, when serving lots of
clients, we recommend using the @option{--cache} option, which enables
caching of the archives before they are sent to clients---see below for
details. The @command{guix weather} command provides a handy way to
check what a server provides (@pxref{Invoking guix weather}).
As a bonus, @command{guix publish} also serves as a content-addressed
mirror for source files referenced in @code{origin} records
(@pxref{origin Reference}). For instance, assuming @command{guix
publish} is running on @code{example.org}, the following URL returns the
raw @file{hello-2.10.tar.gz} file with the given SHA256 hash
(represented in @code{nix-base32} format, @pxref{Invoking guix hash}):
@example
http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1@dots{}ndq1i
@end example
Obviously, these URLs only work for files that are in the store; in
other cases, they return 404 (``Not Found'').
The following options are available:
@table @code
@item --port=@var{port}
@itemx -p @var{port}
Listen for HTTP requests on @var{port}.
@item --listen=@var{host}
Listen on the network interface for @var{host}. The default is to
accept connections from any interface.
@item --user=@var{user}
@itemx -u @var{user}
Change privileges to @var{user} as soon as possible---i.e., once the
server socket is open and the signing key has been read.
@item --compression[=@var{level}]
@itemx -C [@var{level}]
Compress data using the given @var{level}. When @var{level} is zero,
disable compression. The range 1 to 9 corresponds to different gzip
compression levels: 1 is the fastest, and 9 is the best (CPU-intensive).
The default is 3.
Unless @option{--cache} is used, compression occurs on the fly and
the compressed streams are not
cached. Thus, to reduce load on the machine that runs @command{guix
6962
6963
6964
6965
6966
6967
6968
6969
6970
6971
6972
6973
6974
6975
6976
6977
6978
6979
6980
6981
6982
6983
6984
6985
6986
6987
6988
6989
6990
6991
6992
publish}, it may be a good idea to choose a low compression level, to
run @command{guix publish} behind a caching proxy, or to use
@option{--cache}. Using @option{--cache} has the advantage that it
allows @command{guix publish} to add @code{Content-Length} HTTP header
to its responses.
@item --cache=@var{directory}
@itemx -c @var{directory}
Cache archives and meta-data (@code{.narinfo} URLs) to @var{directory}
and only serve archives that are in cache.
When this option is omitted, archives and meta-data are created
on-the-fly. This can reduce the available bandwidth, especially when
compression is enabled, since this may become CPU-bound. Another
drawback of the default mode is that the length of archives is not known
in advance, so @command{guix publish} does not add a
@code{Content-Length} HTTP header to its responses, which in turn
prevents clients from knowing the amount of data being downloaded.
Conversely, when @option{--cache} is used, the first request for a store
item (@i{via} a @code{.narinfo} URL) returns 404 and triggers a
background process to @dfn{bake} the archive---computing its
@code{.narinfo} and compressing the archive, if needed. Once the
archive is cached in @var{directory}, subsequent requests succeed and
are served directly from the cache, which guarantees that clients get
the best possible bandwidth.
The ``baking'' process is performed by worker threads. By default, one
thread per CPU core is created, but this can be customized. See
@option{--workers} below.
When @option{--ttl} is used, cached entries are automatically deleted
when they have expired.
@item --workers=@var{N}
When @option{--cache} is used, request the allocation of @var{N} worker
threads to ``bake'' archives.