Next: Invocando guix refresh
, Previous: Invocando guix hash
, Up: Utilitários [Contents][Index]
guix import
The guix import
command is useful for people who would like to add
a package to the distribution with as little work as possible—a legitimate
demand. The command knows of a few repositories from which it can
“import” package metadata. The result is a package definition, or a
template thereof, in the format we know (see Definindo pacotes).
The general syntax is:
guix import importer options…
importer specifies the source from which to import package metadata, and options specifies a package identifier and other options specific to importer.
Some of the importers rely on the ability to run the gpgv
command. For these, GnuPG must be installed and in $PATH
; run
guix install gnupg
if needed.
Currently, the available “importers” are:
gnu
Import metadata for the given GNU package. This provides a template for the latest version of that GNU package, including the hash of its source tarball, and its canonical synopsis and description.
Additional information such as the package dependencies and its license needs to be figured out manually.
For example, the following command returns a package definition for GNU Hello:
guix import gnu hello
Specific command-line options are:
--key-download=policy
As for guix refresh
, specify the policy to handle missing OpenPGP
keys when verifying the package signature. See --key-download.
pypi
¶Import metadata from the Python Package
Index. Information is taken from the JSON-formatted description available
at pypi.python.org
and usually includes all the relevant information,
including package dependencies. For maximum efficiency, it is recommended
to install the unzip
utility, so that the importer can unzip
Python wheels and gather data from them.
The command below imports metadata for the latest version of the
itsdangerous
Python package:
guix import pypi itsdangerous
You can also ask for a specific version:
guix import pypi itsdangerous@1.1.0
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
gem
¶Import metadata from RubyGems. Information is
taken from the JSON-formatted description available at rubygems.org
and includes most relevant information, including runtime dependencies.
There are some caveats, however. The metadata doesn’t distinguish between
synopses and descriptions, so the same string is used for both fields.
Additionally, the details of non-Ruby dependencies required to build native
extensions is unavailable and left as an exercise to the packager.
The command below imports metadata for the rails
Ruby package:
guix import gem rails
You can also ask for a specific version:
guix import gem rails@7.0.4
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
minetest
¶Import metadata from ContentDB. Information is taken from the JSON-formatted metadata provided through ContentDB’s API and includes most relevant information, including dependencies. There are some caveats, however. The license information is often incomplete. The commit hash is sometimes missing. The descriptions are in the Markdown format, but Guix uses Texinfo instead. Texture packs and subgames are unsupported.
The command below imports metadata for the Mesecons mod by Jeija:
guix import minetest Jeija/mesecons
The author name can also be left out:
guix import minetest mesecons
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
cpan
¶Import metadata from MetaCPAN.
Information is taken from the JSON-formatted metadata provided through
MetaCPAN’s API and includes most
relevant information, such as module dependencies. License information
should be checked closely. If Perl is available in the store, then the
corelist
utility will be used to filter core modules out of the list
of dependencies.
The command command below imports metadata for the Acme::Boolean Perl module:
guix import cpan Acme::Boolean
cran
¶Import metadata from CRAN, the central repository for the GNU R statistical and graphical environment.
Information is extracted from the DESCRIPTION file of the package.
The command command below imports metadata for the Cairo R package:
guix import cran Cairo
You can also ask for a specific version:
guix import cran rasterVis@0.50.3
When --recursive is added, the importer will traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
When --style=specification is added, the importer will generate package definitions whose inputs are package specifications instead of references to package variables. This is useful when generated package definitions are to be appended to existing user modules, as the list of used package modules need not be changed. The default is --style=variable.
When --archive=bioconductor is added, metadata is imported from Bioconductor, a repository of R packages for the analysis and comprehension of high-throughput genomic data in bioinformatics.
Information is extracted from the DESCRIPTION file contained in the package archive.
The command below imports metadata for the GenomicRanges R package:
guix import cran --archive=bioconductor GenomicRanges
Finally, you can also import R packages that have not yet been published on CRAN or Bioconductor as long as they are in a git repository. Use --archive=git followed by the URL of the git repository:
guix import cran --archive=git https://github.com/immunogenomics/harmony
texlive
¶Import TeX package information from the TeX Live package database for TeX packages that are part of the TeX Live distribution.
Information about the package is obtained from the TeX Live package
database, a plain text file that is included in the texlive-bin
package. The source code is downloaded from possibly multiple locations in
the SVN repository of the Tex Live project.
The command command below imports metadata for the fontspec
TeX
package:
guix import texlive fontspec
json
¶Import package metadata from a local JSON file. Consider the following example package definition in JSON format:
{ "name": "hello", "version": "2.10", "source": "mirror://gnu/hello/hello-2.10.tar.gz", "build-system": "gnu", "home-page": "https://www.gnu.org/software/hello/", "synopsis": "Hello, GNU world: An example GNU package", "description": "GNU Hello prints a greeting.", "license": "GPL-3.0+", "native-inputs": ["gettext"] }
The field names are the same as for the <package>
record
(See Definindo pacotes). References to other packages are provided as
JSON lists of quoted package specification strings such as guile
or
guile@2.0
.
The importer also supports a more explicit source definition using the
common fields for <origin>
records:
{ … "source": { "method": "url-fetch", "uri": "mirror://gnu/hello/hello-2.10.tar.gz", "sha256": { "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i" } } … }
The command below reads metadata from the JSON file hello.json
and
outputs a package expression:
guix import json hello.json
hackage
¶Import metadata from the Haskell community’s central package archive Hackage. Information is taken from Cabal files and includes all the relevant information, including package dependencies.
Specific command-line options are:
--stdin
-s
Read a Cabal file from standard input.
--no-test-dependencies
-t
Do not include dependencies required only by the test suites.
--cabal-environment=alist
-e alist
alist is a Scheme alist defining the environment in which the Cabal
conditionals are evaluated. The accepted keys are: os
, arch
,
impl
and a string representing the name of a flag. The value
associated with a flag has to be either the symbol true
or
false
. The value associated with other keys has to conform to the
Cabal file format definition. The default value associated with the keys
os
, arch
and impl
is ‘linux’, ‘x86_64’ and
‘ghc’, respectively.
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
The command below imports metadata for the latest version of the HTTP
Haskell package without including test dependencies and specifying the value
of the flag ‘network-uri’ as false
:
guix import hackage -t -e "'((\"network-uri\" . false))" HTTP
A specific package version may optionally be specified by following the package name by an at-sign and a version number as in the following example:
guix import hackage mtl@2.1.3.1
stackage
¶The stackage
importer is a wrapper around the hackage
one. It
takes a package name, looks up the package version included in a long-term
support (LTS) Stackage release and uses the
hackage
importer to retrieve its metadata. Note that it is up to you
to select an LTS release compatible with the GHC compiler used by Guix.
Specific command-line options are:
--no-test-dependencies
-t
Do not include dependencies required only by the test suites.
--lts-version=versão
-l versão
version is the desired LTS release version. If omitted the latest release is used.
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
The command below imports metadata for the HTTP Haskell package included in the LTS Stackage release version 7.18:
guix import stackage --lts-version=7.18 HTTP
elpa
¶Import metadata from an Emacs Lisp Package Archive (ELPA) package repository (see Packages in The GNU Emacs Manual).
Specific command-line options are:
--archive=repo
-a repo
repo identifies the archive repository from which to retrieve the information. Currently the supported repositories and their identifiers are:
gnu
identifier. This is the default.
Packages from elpa.gnu.org
are signed with one of the keys contained
in the GnuPG keyring at share/emacs/25.1/etc/package-keyring.gpg (or
similar) in the emacs
package (see ELPA
package signatures in The GNU Emacs Manual).
nongnu
identifier.
melpa-stable
identifier.
melpa
identifier.
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
crate
¶Import metadata from the crates.io Rust package repository crates.io, as in this example:
guix import crate blake2-rfc
The crate importer also allows you to specify a version string:
guix import crate constant-time-eq@0.1.0
Additional options include:
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
elm
¶Import metadata from the Elm package repository package.elm-lang.org, as in this example:
guix import elm elm-explorations/webgl
The Elm importer also allows you to specify a version string:
guix import elm elm-explorations/webgl@1.1.3
Additional options include:
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
opam
¶Import metadata from the OPAM package repository used by the OCaml community.
Additional options include:
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
--repo
By default, packages are searched in the official OPAM repository. This option, which can be used more than once, lets you add other repositories which will be searched for packages. It accepts as valid arguments:
opam
,
coq
(equivalent to coq-released
), coq-core-dev
,
coq-extra-dev
or grew
.
opam repository add
command (for instance, the URL equivalent of the
above opam
name would be https://opam.ocaml.org).
Repositories are assumed to be passed to this option by order of
preference. The additional repositories will not replace the default
opam
repository, which is always kept as a fallback.
Also, please note that versions are not compared across repositories. The first repository (from left to right) that has at least one version of a given package will prevail over any others, and the version imported will be the latest one found in this repository only.
go
¶Import metadata for a Go module using proxy.golang.org.
guix import go gopkg.in/yaml.v2
It is possible to use a package specification with a @VERSION
suffix
to import a specific version.
Additional options include:
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
--pin-versions
When using this option, the importer preserves the exact versions of the Go modules dependencies instead of using their latest available versions. This can be useful when attempting to import packages that recursively depend on former versions of themselves to build. When using this mode, the symbol of the package is made by appending the version to its name, so that multiple versions of the same package can coexist.
egg
¶Import metadata for CHICKEN eggs. The information is taken from PACKAGE.egg files found in the eggs-5-all Git repository. However, it does not provide all the information that we need, there is no “description” field, and the licenses used are not always precise (BSD is often used instead of BSD-N).
guix import egg sourcehut
You can also ask for a specific version:
guix import egg arrays@1.0
Additional options include:
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
hexpm
¶Import metadata from the hex.pm Erlang and Elixir package repository hex.pm, as in this example:
guix import hexpm stun
The importer tries to determine the build system used by the package.
The hexpm importer also allows you to specify a version string:
guix import hexpm cf@0.3.0
Additional options include:
--recursive
-r
Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.
The structure of the guix import
code is modular. It would be
useful to have more importers for other package formats, and your help is
welcome here (see Contribuindo).
Next: Invocando guix refresh
, Previous: Invocando guix hash
, Up: Utilitários [Contents][Index]