Another set of command-line options supported by
guix package are package transformation
options. These are options that make it possible to define package
variants—for instance, packages built from different source code.
This is a convenient way to create customized packages on the fly
without having to type in the definitions of package variants
(see Defining Packages).
Use source as the source of package, and version as
its version number.
source must be a file name or a URL, as for
download (see Invoking guix download).
When package is omitted,
it is taken to be the package name specified on the
command line that matches the base of source—e.g.,
if source is
/src/guile-2.0.10.tar.gz, the corresponding
Likewise, when version is omitted, the version string is inferred from
source; in the previous example, it is
This option allows users to try out versions of packages other than the
one provided by the distribution. The example below downloads
ed-1.7.tar.gz from a GNU mirror and uses that as the source for
guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz
As a developer,
--with-source makes it easy to test release
guix build guile --with-source=../guile-188.8.131.52-e1bb7.tar.xz
… or to build from a checkout in a pristine environment:
$ git clone git://git.sv.gnu.org/guix.git $ guix build guix --firstname.lastname@example.org=./guix
Replace dependency on package by a dependency on
replacement. package must be a package name, and
replacement must be a package specification such as
For instance, the following command builds Guix, but replaces its
dependency on the current stable version of Guile with a dependency on
the legacy version of Guile,
guix build --email@example.com guix
This is a recursive, deep replacement. So in this example, both
guix and its dependency
guile-json (which also depends on
guile) get rebuilt against
This is implemented using the
This is similar to
--with-input but with an important difference:
instead of rebuilding the whole dependency chain, replacement is
built and then grafted onto the binaries that were initially
referring to package. See Security Updates, for more
information on grafts.
For example, the command below grafts version 3.5.4 of GnuTLS onto Wget and all its dependencies, replacing references to the version of GnuTLS they currently refer to:
guix build --firstname.lastname@example.org wget
This has the advantage of being much faster than rebuilding everything. But there is a caveat: it works if and only if package and replacement are strictly compatible—for example, if they provide a library, the application binary interface (ABI) of those libraries must be compatible. If replacement is somehow incompatible with package, then the resulting package may be unusable. Use with care!
Build package from the latest commit of branch. The
field of package must be an origin with the
(see origin Reference) or a
git-checkout object; the repository URL
is taken from that
For instance, the following command builds
guile-sqlite3 from the
latest commit of its
master branch, and then builds
depends on it) and
cuirass (which depends on
guix) against this
guix build --with-branch=guile-sqlite3=master cuirass
Obviously, since it uses the latest commit of the given branch, the result of such a command varies over time. Nevertheless it is a convenient way to rebuild entire software stacks against the latest commit of one or more packages. This is particularly useful in the context of continuous integration (CI).
Checkouts are kept in a cache under ~/.cache/guix/checkouts to speed up consecutive accesses to the same repository. You may want to clean it up once in a while to save disk space.
This is similar to
--with-branch, except that it builds from
commit rather than the tip of a branch. commit must be a valid
Git commit SHA1 identifier.