Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help 
nix-store --export(1)	    General Commands Manual	 nix-store --export(1)

Name
       nix-store   --export   -	  export   store   paths   to  a  Nix  Archive
       <../../store/file-system-object/content-address.md#serial-nix-archive>

   Synopsis
       nix-store --export paths

   Description
       The operation --export writes a serialisation of	the  given  store  ob-
       jects  <../../glossary.md#gloss-store-object>  to  standard output in a
       format	that   can   be	   imported    into    another	  Nix	 store
       <../../store/index.md> with nix-store --import <./import.md>.

	      Warning

	      This	command	    does     not     produce	 a     closure
	      <../../glossary.md#gloss-closure>	of the specified store	paths.
	      Trying  to  import a store object	that refers to store paths not
	      available	in the target Nix store	will fail.

	      Use nix-store --query <../../command-ref/nix-store/query.md>  to
	      obtain the closure of a store path.

       This command is different from nix-store	--dump <./dump.md>, which pro-
       duces a Nix archive <../../glossary.md#gloss-nar> that does not contain
       the  set	 of  references	<../../glossary.md#gloss-reference> of a given
       store path.

	      Note

	      For efficient transfer of	closures to remote machines over  SSH,
	      use nix-copy-closure <../../command-ref/nix-copy-closure.md>.

Options
       The following options are allowed for all nix-store operations, but may
       not always have an effect.

       •  --add-root <#opt-add-root> path

	  Causes  the  result of a realisation (--realise and --force-realise)
	  to be	registered as a	root of	the garbage collector.	path  will  be
	  created  as  a  symlink  to the resulting store path.	In addition, a
	  uniquely named symlink to path will be created  in  /nix/var/nix/gc-
	  roots/auto/. For instance,

       $ nix-store --add-root /home/eelco/bla/result --realise ...

       $ ls -l /nix/var/nix/gcroots/auto
       lrwxrwxrwx    1 ... 2005-03-13 21:10 dn54lcypm8f8... -> /home/eelco/bla/result

       $ ls -l /home/eelco/bla/result
       lrwxrwxrwx    1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r11343n6qd4...-f-spot-0.0.10

	      Thus, when /home/eelco/bla/result	is removed, the	GC root	in the
	      auto directory becomes a dangling	symlink	and will be ignored by
	      the collector.

		     Warning

		     Note  that	it is not possible to move or rename GC	roots,
		     since the symlink in the auto directory will still	 point
		     to	the old	location.

	      If  there	 are  multiple results,	then multiple symlinks will be
	      created by sequentially numbering	symlinks beyond	the first  one
	      (e.g., foo, foo-2, foo-3,	and so on).

Common Options
       Most Nix	commands accept	the following command-line options:

       •  --help <#opt-help>

	  Prints out a summary of the command syntax and exits.

       •  --version <#opt-version>

	  Prints out the Nix version number on standard	output and exits.

       •  --verbose <#opt-verbose> / -v

	  Increases  the  level	of verbosity of	diagnostic messages printed on
	  standard error.  For each Nix	operation, the information printed  on
	  standard  output  is	well-defined;  any  diagnostic	information is
	  printed on standard error, never on standard output.

	  This option may be specified repeatedly.  Currently,	the  following
	  verbosity levels exist:

	  •  0 Errors only

	  Only print messages explaining why the Nix invocation	failed.

	  •  1 Informational

	  Print	useful messages	about what Nix is doing.  This is the default.

	  •  2 Talkative

	  Print	more informational messages.

	  •  3 Chatty

	  Print	even more informational	messages.

	  •  4 Debug

	  Print	debug information.

	  •  5 Vomit

	  Print	vast amounts of	debug information.

       •  --quiet <#opt-quiet>

	  Decreases  the  level	of verbosity of	diagnostic messages printed on
	  standard error.  This	is the inverse option to -v / --verbose.

	  This option may be specified repeatedly.  See	the previous verbosity
	  levels list.

       •  --log-format <#opt-log-format> format

	  This option can be used to change the	output of the log format, with
	  format being one of:

	  •  raw

	  This is the raw format, as outputted by nix-build.

	  •  internal-json

	  Outputs the logs in a	structured manner.

		 Warning

		 While the schema itself is relatively stable, the  format  of
		 the  error-messages  (namely of the msg-field)	can change be-
		 tween releases.

	  •  bar

	  Only display a progress bar during the builds.

	  •  bar-with-logs

	  Display the raw logs,	with the progress bar at the bottom.

       •  --no-build-output <#opt-no-build-output> / -Q

	  By default, output written by	builders to standard output and	 stan-
	  dard	error is echoed	to the Nix command's standard error.  This op-
	  tion suppresses this behaviour.  Note	that  the  builder's  standard
	  output  and  error  are  always  written  to	a  log	file  in  pre-
	  fix/nix/var/log/nix.

       •  --max-jobs <#opt-max-jobs> / -j number

	  Sets the maximum number of build jobs	that Nix will perform in  par-
	  allel	 to  the  specified number.  Specify auto to use the number of
	  CPUs in the system.  The default is specified	by the	max-jobs  con-
	  figuration  setting,	which itself defaults to 1.  A higher value is
	  useful on SMP	systems	or to exploit I/O latency.

	  Setting it to	0 disallows building on	the local  machine,  which  is
	  useful when you want builds to happen	only on	remote builders.

       •  --cores <#opt-cores>

	  Sets	the  value  of the NIX_BUILD_CORES environment variable	in the
	  invocation of	builders.  Builders can	use  this  variable  at	 their
	  discretion  to  control  the maximum amount of parallelism.  For in-
	  stance, in Nixpkgs, if the derivation	attribute enableParallelBuild-
	  ing is set to	true, the builder passes the -jN flag to GNU Make.  It
	  defaults to the value	of the cores configuration setting, if set, or
	  1 otherwise.	The value 0 means that	the  builder  should  use  all
	  available CPU	cores in the system.

       •  --max-silent-time <#opt-max-silent-time>

	  Sets	the  maximum  number  of seconds that a	builder	can go without
	  producing any	data on	standard output	or standard  error.   The  de-
	  fault	 is specified by the max-silent-time configuration setting.  0
	  means	no time-out.

       •  --timeout <#opt-timeout>

	  Sets the maximum number of seconds that a builder can	run.  The  de-
	  fault	is specified by	the timeout configuration setting.  0 means no
	  timeout.

       •  --keep-going <#opt-keep-going> / -k

	  Keep	going  in case of failed builds, to the	greatest extent	possi-
	  ble.	That is, if building an	input of some  derivation  fails,  Nix
	  will	still  build  the other	inputs,	but not	the derivation itself.
	  Without this option, Nix stops if any	build fails (except for	builds
	  of substitutes), possibly killing builds in  progress	 (in  case  of
	  parallel or distributed builds).

       •  --keep-failed	<#opt-keep-failed> / -K

	  Specifies  that  in case of a	build failure, the temporary directory
	  (usually in /tmp) in which the  build	 takes	place  should  not  be
	  deleted.   The path of the build directory is	printed	as an informa-
	  tional message.

       •  --fallback <#opt-fallback>

	  Whenever Nix attempts	to build a derivation  for  which  substitutes
	  are  known  for  each	 output	 path,	but realising the output paths
	  through the substitutes fails, fall back on building the derivation.

	  The most common scenario in which this is useful  is	when  we  have
	  registered substitutes in order to perform binary distribution from,
	  say,	a network repository.  If the repository is down, the realisa-
	  tion of the derivation will fail.  When this	option	is  specified,
	  Nix  will build the derivation instead.  Thus, installation from bi-
	  naries falls back on installation from source.  This option  is  not
	  the  default	since  it  is  generally not desirable for a transient
	  failure in obtaining the substitutes to lead to a  full  build  from
	  source (with the related consumption of resources).

       •  --readonly-mode <#opt-readonly-mode>

	  When	this  option is	used, no attempt is made to open the Nix data-
	  base.	 Most Nix operations do	need database access, so those	opera-
	  tions	will fail.

       •  --arg	<#opt-arg> name	value

	  This	option	is accepted by nix-env,	nix-instantiate, nix-shell and
	  nix-build.  When evaluating Nix expressions, the expression  evalua-
	  tor will automatically try to	call functions that it encounters.  It
	  can  automatically call functions for	which every argument has a de-
	  fault	value <../../language/syntax.md#functions> (e.g., { argName  ?
	  defaultValue }: ...).

	  With	--arg, you can also call functions that	have arguments without
	  a default value (or override a default  value).   That  is,  if  the
	  evaluator encounters a function with an argument named name, it will
	  call it with value value.

	  For  instance,  the  top-level  default.nix in Nixpkgs is actually a
	  function:

       { # The system (e.g., `i686-linux') for which to	build the packages.
       system ?	builtins.currentSystem
       ...
       }: ...

	      So if you	call this Nix expression (e.g.,	when  you  do  nix-env
	      --install	--attr pkgname), the function will be called automati-
	      cally	 using	    the	     value	builtins.currentSystem
	      <../../language/builtins.md> for the system argument.   You  can
	      override	this  using --arg, e.g., nix-env --install --attr pkg-
	      name --arg system	\"i686-freebsd\".  (Note that since the	 argu-
	      ment is a	Nix string literal, you	have to	escape the quotes.)

       •  --arg-from-file <#opt-arg-from-file> name path

	  Pass	the  contents  of  file	path as	the argument name to Nix func-
	  tions.

       •  --arg-from-stdin <#opt-arg-from-stdin> name

	  Pass the contents of stdin as	the argument name to Nix functions.

       •  --argstr <#opt-argstr> name value

	  This option is like --arg, only the value is not  a  Nix  expression
	  but  a string.  So instead of	--arg system \"i686-linux\" (the outer
	  quotes are to	keep the shell happy)  you  can	 say  --argstr	system
	  i686-linux.

       •  --attr <#opt-attr> / -A attrPath

	  Select  an  attribute	from the top-level Nix expression being	evalu-
	  ated.	 (nix-env, nix-instantiate,  nix-build	and  nix-shell	only.)
	  The  attribute  path attrPath	is a sequence of attribute names sepa-
	  rated	by dots.  For instance,	given a	top-level  Nix	expression  e,
	  the  attribute  path	xorg.xorgserver	 would	cause  the  expression
	  e.xorg.xorgserver to be used.	 See nix-env --install <../../command-
	  ref/nix-env/install.md> for some concrete examples.

	  In addition to attribute names, you can also specify array  indices.
	  For instance,	the attribute path foo.3.bar selects the bar attribute
	  of  the fourth element of the	array in the foo attribute of the top-
	  level	expression.

       •  --eval-store <#opt-eval-store> store-url

	  The URL  to  the  Nix	 store	<../../store/types/index.md#store-url-
	  format> to use for evaluation, i.e. where to store derivations (.drv
	  files) and inputs referenced by them.

       •  --expr <#opt-expr> / -E

	  Interpret the	command	line arguments as a list of Nix	expressions to
	  be  parsed and evaluated, rather than	as a list of file names	of Nix
	  expressions.	(nix-instantiate, nix-build and	nix-shell only.)

	  For nix-shell, this option is	commonly used to give you a  shell  in
	  which	you can	build the packages returned by the expression.	If you
	  want	to get a shell which contain the built packages	ready for use,
	  give your expression to the nix-shell	 --packages  convenience  flag
	  instead.

       •  -I / --include <#opt-I> path

	  Add  an  entry  to  the  list	of search paths	used to	resolve	lookup
	  paths	<../../language/constructs/lookup-path.md>.  This  option  may
	  be given multiple times.

	  Paths	 added through -I take precedence over the nix-path configura-
	  tion setting <../../command-ref/conf-file.md#conf-nix-path> and  the
	  NIX_PATH  environment	variable <../../command-ref/env-common.md#env-
	  NIX_PATH>.

       •  --impure <#opt-impure>

	  Allow	access to mutable paths	and repositories.

       •  --option <#opt-option> name value

	  Set the Nix configuration option name	to value.  This	overrides set-
	  tings	in the Nix configuration file (see nix.conf5).

       •  --repair <#opt-repair>

	  Fix corrupted	or missing store paths by redownloading	or  rebuilding
	  them.	  Note that this is slow because it requires computing a cryp-
	  tographic hash of the	contents of every path in the closure  of  the
	  build.  Also note the	warning	under nix-store	--repair-path.

	  Note

	  See man nix.conf <../../command-ref/conf-file.md#command-line-flags>
	  for overriding configuration settings	with command line flags.

Common Environment Variables
       Most Nix	commands interpret the following environment variables:

       •  IN_NIX_SHELL <#env-IN_NIX_SHELL>

	  Indicator  that  tells if the	current	environment was	set up by nix-
	  shell. It can	have the values	pure or	impure.

       •  NIX_PATH <#env-NIX_PATH>

	  A colon-separated list of search path	entries	used to	resolve	lookup
	  paths	<../../language/constructs/lookup-path.md>.

	  This environment variable overrides the value	of the	nix-path  con-
	  figuration setting <../../command-ref/conf-file.md#conf-nix-path>.

	  It  can  be extended using the -I option <../../command-ref/opt-com-
	  mon.md#opt-I>.

		 Example

	  $ export NIX_PATH=`/home/eelco/Dev:nixos-config=/etc/nixos

	  If NIX_PATH is set to	an empty string, resolving search  paths  will
	  always fail.

		 Example

	  $ NIX_PATH= nix-instantiate --eval '<nixpkgs>'
	  error: file 'nixpkgs'	was not	found in the Nix search	path (add it using $NIX_PATH or	-I)

       •  NIX_IGNORE_SYMLINK_STORE <#env-NIX_IGNORE_SYMLINK_STORE>

	  Normally,  the Nix store directory (typically	/nix/store) is not al-
	  lowed	to contain any symlink components. This	is to  prevent	impure
	  builds.  Builders sometimes canonicalise paths by resolving all sym-
	  link components. Thus, builds	on different machines (with /nix/store
	  resolving to different locations)  could  yield  different  results.
	  This	is generally not a problem, except when	builds are deployed to
	  machines where /nix/store resolves differently. If you are sure that
	  youre	not going to do	that, you can set NIX_IGNORE_SYMLINK_STORE  to
	  1.

	  Note	that  if youre symlinking the Nix store	so that	you can	put it
	  on another file system than the root file  system,  on  Linux	 youre
	  better off using bind	mount points, e.g.,

       $ mkdir /nix
       $ mount -o bind /mnt/otherdisk/nix /nix

	      Consult the mount	8 manual page for details.

       •  NIX_STORE_DIR	<#env-NIX_STORE_DIR>

	  Overrides the	location of the	Nix store (default prefix/store).

       •  NIX_DATA_DIR <#env-NIX_DATA_DIR>

	  Overrides  the  location  of	the Nix	static data directory (default
	  prefix/share).

       •  NIX_LOG_DIR <#env-NIX_LOG_DIR>

	  Overrides the	location  of  the  Nix	log  directory	(default  pre-
	  fix/var/log/nix).

       •  NIX_STATE_DIR	<#env-NIX_STATE_DIR>

	  Overrides  the  location  of	the  Nix state directory (default pre-
	  fix/var/nix).

       •  NIX_CONF_DIR <#env-NIX_CONF_DIR>

	  Overrides the	location of the	 system	 Nix  configuration  directory
	  (default sysconfdir/nix, i.e.	/etc/nix on most systems).

       •  NIX_CONFIG <#env-NIX_CONFIG>

	  Applies  settings  from Nix configuration from the environment.  The
	  content is treated as	if it was read from a Nix configuration	 file.
	  Settings are separated by the	newline	character.

       •  NIX_USER_CONF_FILES <#env-NIX_USER_CONF_FILES>

	  Overrides  the  location of the Nix user configuration files to load
	  from.

	  The default are the locations	according to the  XDG  Base  Directory
	  Specification	      <https://specifications.freedesktop.org/basedir-
	  spec/basedir-spec-latest.html>.  See the XDG Base Directories	<#xdg-
	  base-directories> sub-section	for details.

	  The variable is treated as a list separated by the : token.

       •  TMPDIR <#env-TMPDIR>

	  Use the specified directory to store temporary files.	In particular,
	  this includes	temporary build	directories; these can	take  up  sub-
	  stantial amounts of disk space. The default is /tmp.

       •  NIX_REMOTE <#env-NIX_REMOTE>

	  This	variable  should  be  set to daemon if you want	to use the Nix
	  daemon to execute Nix	operations. This is  necessary	in  multi-user
	  Nix  installations  <../../installation/multi-user.md>.  If  the Nix
	  daemon's Unix	socket is at some  non-standard	 path,	this  variable
	  should be set	to unix://path/to/socket. Otherwise, it	should be left
	  unset.

       •  NIX_SHOW_STATS <#env-NIX_SHOW_STATS>

	  If  set to 1,	Nix will print some evaluation statistics, such	as the
	  number of values allocated.

       •  NIX_COUNT_CALLS <#env-NIX_COUNT_CALLS>

	  If set to 1, Nix will	print how often	functions were	called	during
	  Nix expression evaluation. This is useful for	profiling your Nix ex-
	  pressions.

       •  GC_INITIAL_HEAP_SIZE <#env-GC_INITIAL_HEAP_SIZE>

	  If  Nix has been configured to use the Boehm garbage collector, this
	  variable sets	the initial size of the	heap in	bytes. It defaults  to
	  384  MiB.  Setting it	to a low value reduces memory consumption, but
	  will increase	runtime	due to the overhead of garbage collection.

   XDG Base Directories
       Nix follows the XDG Base	 Directory  Specification  <https://specifica-
       tions.freedesktop.org/basedir-spec/basedir-spec-latest.html>.

       For backwards compatibility, Nix	commands will follow the standard only
       when use-xdg-base-directories <../../command-ref/conf-file.md#conf-use-
       xdg-base-directories>  is  enabled.   New  Nix commands <../../command-
       ref/new-cli/nix.md> (experimental) conform to the standard by default.

       The following environment variables are used to determine locations  of
       various state and configuration files:

       •  [XDG_CONFIG_HOME]{#env-XDGCONFIGHOME}	(default ~/.config)
       •  [XDG_STATE_HOME]{#env-XDGSTATEHOME} (default ~/.local/state)
       •  [XDG_CACHE_HOME]{#env-XDGCACHEHOME} (default ~/.cache)

       In  addition, setting the following environment variables overrides the
       XDG base	directories:

       •  [NIX_CONFIG_HOME]{#env-NIXCONFIGHOME}	(default $XDG_CONFIG_HOME/nix)
       •  [NIX_STATE_HOME]{#env-NIXSTATEHOME} (default $XDG_STATE_HOME/nix)
       •  [NIX_CACHE_HOME]{#env-NIXCACHEHOME} (default $XDG_CACHE_HOME/nix)

       When use-xdg-base-directories <../../command-ref/conf-file.md#conf-use-
       xdg-base-directories> is	enabled, the configuration directory is:

       1. $NIX_CONFIG_HOME, if it is defined
       2. Otherwise, $XDG_CONFIG_HOME/nix, if XDG_CONFIG_HOME is defined
       3. Otherwise, ~/.config/nix.

       Likewise	for the	state and cache	directories.

Examples
	      Example

	      Deploy GNU Hello to an airgapped machine via USB stick.

	      Write the	closure	to the block device on a machine with internet
	      connection:

	      [alice@itchy]$ storePath=$(nix-build '<nixpkgs>' -I nixpkgs=channel:nixpkgs-unstable -A hello --no-out-link)
	      [alice@itchy]$ nix-store --export	$(nix-store --query --requisites $storePath) | sudo dd of=/dev/usb

	      Read the closure from the	block device on	 the  machine  without
	      internet connection:

	      [bob@scratchy]$ hello=$(sudo dd if=/dev/usb | nix-store --import | tail -1)
	      [bob@scratchy]$ $hello/bin/hello
	      Hello, world!

							 nix-store --export(1)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=nix-store-export&sektion=1&manpath=FreeBSD+Ports+15.0>

home | help