Jump to content

FAQ/zh: Difference between revisions

From NixOS Wiki
Ardenet (talk | contribs)
No edit summary
Tags: Mobile edit Mobile web edit
FuzzyBot (talk | contribs)
Updating to match new version of source page
Line 1: Line 1:
<languages/>
<languages/>
<div class="mw-translate-fuzzy">
{{cleanup}}
为了避免重复回答那些经常被问到的问题以及处理新手常遇到的麻烦,这些问题被收录在这里。
为了避免重复回答那些经常被问到的问题以及处理新手常遇到的麻烦,这些问题被收录在这里。
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 37: Line 36:
=== 如何保留构建时依赖/在离线状态下重新构建? ===
=== 如何保留构建时依赖/在离线状态下重新构建? ===


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix"># /etc/nixos/configuration.nix
<syntaxhighlight lang="nix"># /etc/nixos/configuration.nix
{ config, pkgs, lib, ... }:
{ config, pkgs, lib, ... }:
Line 48: Line 46:
   };
   };
}</syntaxhighlight>
}</syntaxhighlight>
<div lang="en" dir="ltr" class="mw-content-ltr">
Check 'man configuration.nix' for these options. Rebuild for these options to take effect:
Check 'man configuration.nix' for these options. Rebuild for these options to take effect:
</div>
</div>
<syntaxhighlight lang="bash">nixos-rebuild switch</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nixos-rebuild switch</syntaxhighlight>
List all store paths that form the system closure and realise them:
List all store paths that form the system closure and realise them:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
nix-store -qR $(nix-instantiate '<nixpkgs/nixos>' -A system) | xargs nix-store -r
nix-store -qR $(nix-instantiate '<nixpkgs/nixos>' -A system) | xargs nix-store -r
warning: you did not specify `--add-root'; the result might be removed by the garbage collector
warning: you did not specify `--add-root'; the result might be removed by the garbage collector
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<build output and list of successfully realised paths>
<build output and list of successfully realised paths>
</syntaxhighlight>
</syntaxhighlight>
<div lang="en" dir="ltr" class="mw-content-ltr">
Repeat for your user and further profiles:
Repeat for your user and further profiles:
</div>
</div>
<syntaxhighlight lang="bash">nix-store -qR ~/.nix-profile | xargs nix-store -r</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-store -qR ~/.nix-profile | xargs nix-store -r</syntaxhighlight>
The warning can be ignored for profiles that are listed/linked in ''/nix/var/nix/profiles/'' or one of its subdirectories.
The warning can be ignored for profiles that are listed/linked in ''/nix/var/nix/profiles/'' or one of its subdirectories.
</div>
</div>
Line 94: Line 95:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
q0yi2nr8i60gm2zap46ryysydd2nhzhp-automake-1.11.1/
q0yi2nr8i60gm2zap46ryysydd2nhzhp-automake-1.11.1/
Line 106: Line 106:
xvs7y09jf7j48p6l0p87iypgpq470jqw-nixos-build-vms/
xvs7y09jf7j48p6l0p87iypgpq470jqw-nixos-build-vms/
</syntaxhighlight>
</syntaxhighlight>
</div>


<span id="I&#039;ve_updated_my_channel_and_something_is_broken,_how_can_I_rollback_to_an_earlier_channel?"></span>
<span id="I&#039;ve_updated_my_channel_and_something_is_broken,_how_can_I_rollback_to_an_earlier_channel?"></span>
Line 113: Line 112:
查看可用的各代 channel:
查看可用的各代 channel:


<syntaxhighlight lang="bash">
nix-env --list-generations -p /nix/var/nix/profiles/per-user/root/channels
18  2014-04-17 09:16:28
19  2014-06-13 10:31:24
20  2014-08-12 19:09:20  (current)
</syntaxhighlight>
<div class="mw-translate-fuzzy">
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
nix-env --list-generations -p /nix/var/nix/profiles/per-user/root/channels
nix-env --list-generations -p /nix/var/nix/profiles/per-user/root/channels
Line 120: Line 127:
</syntaxhighlight>
</syntaxhighlight>
回滚到上一代的方法如下:
回滚到上一代的方法如下:
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
nix-env --rollback -p /nix/var/nix/profiles/per-user/root/channels
nix-env --rollback -p /nix/var/nix/profiles/per-user/root/channels
switching from generation 20 to 19
switching from generation 20 to 19
</syntaxhighlight>
</syntaxhighlight>
<div lang="en" dir="ltr" class="mw-content-ltr">
To switch to a particular generation:
To switch to a particular generation:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
nix-env --switch-generation 18 -p /nix/var/nix/profiles/per-user/root/channels
nix-env --switch-generation 18 -p /nix/var/nix/profiles/per-user/root/channels
switching from generation 20 to 18
switching from generation 20 to 18
</syntaxhighlight>
</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
=== I'm working on a new package, how can I build it without adding it to nixpkgs? ===
=== I'm working on a new package, how can I build it without adding it to nixpkgs? ===
</div>
</div>
<syntaxhighlight lang="bash">nix-build -E 'with import <nixpkgs> { }; callPackage ./mypackage.nix { }'</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-build -E 'with import <nixpkgs> { }; callPackage ./mypackage.nix { }'</syntaxhighlight>
You can replace callPackage with callPackage_i686 to build the 32-bit version of your package on a 64-bit system if you want to test that.
You can replace callPackage with callPackage_i686 to build the 32-bit version of your package on a 64-bit system if you want to test that.
</div>
</div>
Line 153: Line 161:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-build -E 'with import <nixpkgs> { }; enableDebugging fooPackage'</syntaxhighlight>
<syntaxhighlight lang="bash">nix-build -E 'with import <nixpkgs> { }; enableDebugging fooPackage'</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 168: Line 174:
As root you can run nix-build with the --check flag:
As root you can run nix-build with the --check flag:
</div>
</div>
<syntaxhighlight lang="bash">sudo nix-build --check -A ncdu</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">sudo nix-build --check -A ncdu</syntaxhighlight>
=== How can I manage software with nix-env like with configuration.nix? ===
=== How can I manage software with nix-env like with configuration.nix? ===
</div>
</div>
Line 178: Line 185:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<ol style="list-style-type: decimal;">
<ol style="list-style-type: decimal;">
<li><p>Create a meta package called ''userPackages'' your ''~/.config/nixpkgs/config.nix'' file with the packages you would like to have in your environment:</p>
<li><p><span lang="en" dir="ltr" class="mw-content-ltr">Create a meta package called ''userPackages'' your ''~/.config/nixpkgs/config.nix'' file with the packages you would like to have in your environment:</span></p>
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
with (import <nixpkgs> {});
with (import <nixpkgs> {});
Line 195: Line 201:
}
}
</syntaxhighlight></li>
</syntaxhighlight></li>
<li><p>Install all specified packages using this command:</p>
<li><p><span lang="en" dir="ltr" class="mw-content-ltr">Install all specified packages using this command:</span></p>
<syntaxhighlight lang="bash">nix-env -iA userPackages -f '<nixpkgs>'</syntaxhighlight></li></ol>
<syntaxhighlight lang="bash">nix-env -iA userPackages -f '<nixpkgs>'</syntaxhighlight></li></ol>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 209: Line 214:
<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
=== I've downloaded a binary, but I can't run it, what can I do? ===
=== I've downloaded a binary, but I can't run it, what can I do? ===
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
Binaries normally do not work out of the box when you download them because they normally just assume that libraries can be found in hardcoded paths such as <code>/lib</code>. However this assumption is incorrect on NixOS systems due to the inner workings of <code>nix</code> - there is no default path, everything gets set to the corresponding version on compile time.
Binaries normally do not work out of the box when you download them because they normally just assume that libraries can be found in hardcoded paths such as <code>/lib</code>. However this assumption is incorrect on NixOS systems due to the inner workings of <code>nix</code> - there is no default path, everything gets set to the corresponding version on compile time.
</div>
</div>
Line 224: Line 232:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
programs.nix-ld = {
programs.nix-ld = {
Line 230: Line 237:
   libraries = [ pkgs.zlib pkgs.openssl ];
   libraries = [ pkgs.zlib pkgs.openssl ];
};</syntaxhighlight>
};</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 240: Line 246:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
programs.nix-ld = {
programs.nix-ld = {
Line 246: Line 251:
   libraries = pkgs.steam-run.args.multiPkgs pkgs;
   libraries = pkgs.steam-run.args.multiPkgs pkgs;
};</syntaxhighlight>
};</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 256: Line 260:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
# mybinaryprogram.nix
# mybinaryprogram.nix
Line 277: Line 280:
   '';
   '';
}</syntaxhighlight>
}</syntaxhighlight>
<div lang="en" dir="ltr" class="mw-content-ltr">
This can be built with:
This can be built with:
</div>
</div>
<syntaxhighlight lang="bash">nix-build mybinaryprogram.nix</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-build mybinaryprogram.nix</syntaxhighlight>
And run with:
And run with:
</div>
</div>
<syntaxhighlight lang="bash">./result/bin/mybinaryprogram</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">./result/bin/mybinaryprogram</syntaxhighlight>
Another possibility is using a FHS-compatible Sandbox with [https://nixos.org/nixpkgs/manual/#sec-fhs-environments buildFHSUserEnv]
Another possibility is using a FHS-compatible Sandbox with [https://nixos.org/nixpkgs/manual/#sec-fhs-environments buildFHSUserEnv]
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
# fhsUser.nix
# fhsUser.nix
Line 312: Line 318:
   runScript = "bash";
   runScript = "bash";
}).env</syntaxhighlight>
}).env</syntaxhighlight>
<div lang="en" dir="ltr" class="mw-content-ltr">
the sandbox can be entered with
the sandbox can be entered with
</div>
</div>
<syntaxhighlight lang="bash">nix-shell fhsUser.nix</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-shell fhsUser.nix</syntaxhighlight>
<br>
If your target application can't find shared libraries inside buildFHSUserEnv, you may run [https://github.com/lexleogryfon/de-generate nix-de-generate] for target application inside FHS, which will generate newenv.nix file, an nix-expression of buildFHSUserEnv with resolved dependencies for shared libraries.
If your target application can't find shared libraries inside buildFHSUserEnv, you may run [https://github.com/lexleogryfon/de-generate nix-de-generate] for target application inside FHS, which will generate newenv.nix file, an nix-expression of buildFHSUserEnv with resolved dependencies for shared libraries.
</div>
</div>
Line 323: Line 331:
<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
=== What are channels and how do they get updated? ===
=== What are channels and how do they get updated? ===
</div>
{{main|Channel branches}}
{{main|Channel branches}}
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 366: Line 375:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
 
<ol start="2" style="list-style-type: decimal;">
<ol start="2" style="list-style-type: decimal;">
<li>Once the job succeeds at a particular nixpkgs commit, '''cache.nixos.org''' will download binaries from '''hydra.nixos.org'''.</li>
<li><span lang="en" dir="ltr" class="mw-content-ltr">Once the job succeeds at a particular nixpkgs commit, '''cache.nixos.org''' will download binaries from '''hydra.nixos.org'''.</span></li>
<li>Once the above download completes, the channel updates.</li></ol>
<li><span lang="en" dir="ltr" class="mw-content-ltr">Once the above download completes, the channel updates.</span></li>
</div>
</ol>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 387: Line 396:
If you want to know where <nixpkgs> is located:
If you want to know where <nixpkgs> is located:
</div>
</div>
<syntaxhighlight lang="bash">nix-instantiate --find-file nixpkgs</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-instantiate --find-file nixpkgs</syntaxhighlight>
To know the commit, open the .version-suffix file in the nixpkgs location. The hash after the dot is the git commit.
To know the commit, open the .version-suffix file in the nixpkgs location. The hash after the dot is the git commit.
</div>
</div>
Line 395: Line 405:
<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
=== Nixpkgs branches ===
=== Nixpkgs branches ===
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
Branches on the nixpkgs repo have a relationship with channels, but that relationship is not 1:1.
Branches on the nixpkgs repo have a relationship with channels, but that relationship is not 1:1.
</div>
</div>
Line 419: Line 432:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="command">
<syntaxhighlight lang="command">
NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs/archive/release-17.09.tar.gz nix-shell -p $software
NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs/archive/release-17.09.tar.gz nix-shell -p $software
</syntaxhighlight>
</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 456: Line 467:
start a new shell with a private mount namespace (Linux-only)
start a new shell with a private mount namespace (Linux-only)
</div>
</div>
<syntaxhighlight lang="bash">sudo unshare -m bash</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">sudo unshare -m bash</syntaxhighlight>
remount the filesystem with write privileges (as root)
remount the filesystem with write privileges (as root)
</div>
</div>
<syntaxhighlight lang="bash">mount -o remount,rw /nix/store</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">mount -o remount,rw /nix/store</syntaxhighlight>
update the file
update the file
</div>
</div>
<syntaxhighlight lang="bash">nano <PATH_TO_PACKAGE>/default.nix</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nano <PATH_TO_PACKAGE>/default.nix</syntaxhighlight>
exit to shell where /nix/store is still mounted read-only
exit to shell where /nix/store is still mounted read-only
</div>
</div>
<syntaxhighlight lang="bash">exit</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">exit</syntaxhighlight>
Be sure to [https://github.com/NixOS/nixpkgs/issues report the incorrect url] or [https://github.com/NixOS/nixpkgs/pulls fix it yourself].
Be sure to [https://github.com/NixOS/nixpkgs/issues report the incorrect url] or [https://github.com/NixOS/nixpkgs/pulls fix it yourself].
</div>
</div>
Line 489: Line 504:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-prefetch-git https://git.zx2c4.com/password-store</syntaxhighlight>
<syntaxhighlight lang="bash">nix-prefetch-git https://git.zx2c4.com/password-store</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 533: Line 546:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nixos-rebuild switch --option binary-caches ''</syntaxhighlight>
<syntaxhighlight lang="bash">nixos-rebuild switch --option binary-caches ''</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 545: Line 556:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
# /etc/nix/nix.conf
# /etc/nix/nix.conf
Line 551: Line 561:
build-sandbox-paths = $(nix-store -qR $(nix-build '<nixpkgs>' -A bash) | xargs echo /bin/sh=$(nix-build '<nixpkgs>' -A bash)/bin/bash)
build-sandbox-paths = $(nix-store -qR $(nix-build '<nixpkgs>' -A bash) | xargs echo /bin/sh=$(nix-build '<nixpkgs>' -A bash)/bin/bash)
</syntaxhighlight>
</syntaxhighlight>
<div lang="en" dir="ltr" class="mw-content-ltr">
On NixOS set the following in ''configuration.nix'':
On NixOS set the following in ''configuration.nix'':
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
nix.settings.sandbox = true;
nix.settings.sandbox = true;
</syntaxhighlight>
</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 572: Line 582:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-shell -I nixpkgs=channel:nixpkgs-unstable -p somepackage</syntaxhighlight>
<syntaxhighlight lang="bash">nix-shell -I nixpkgs=channel:nixpkgs-unstable -p somepackage</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
It is possible to have multiple nix-channels simultaneously. To add the unstable channel with the specifier ''unstable'',
It is possible to have multiple nix-channels simultaneously. To add the unstable channel with the specifier ''unstable'',
</div>
</div>
<syntaxhighlight lang="bash">sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos-unstable</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos-unstable</syntaxhighlight>
After updating the channel
After updating the channel
</div>
</div>
<syntaxhighlight lang="bash">sudo nix-channel --update nixos-unstable</syntaxhighlight>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">sudo nix-channel --update nixos-unstable</syntaxhighlight>
queries via <code>nix-env</code> will show packages from both ''stable'' and ''unstable''. Use this to install unstable packages into your user environment. The following snippet shows how this can be done in ''configuration.nix''.
queries via <code>nix-env</code> will show packages from both ''stable'' and ''unstable''. Use this to install unstable packages into your user environment. The following snippet shows how this can be done in ''configuration.nix''.
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
{ config, pkgs, ... }:
{ config, pkgs, ... }:
Line 599: Line 608:
}
}
</syntaxhighlight>
</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
This only changes what version of <code>PACKAGE_NAME</code> is available on <code>$PATH</code>. If the package you want to take from unstable is installed through a NixOS module, you must use [[overlays]]:
This only changes what version of <code>PACKAGE_NAME</code> is available on <code>$PATH</code>. If the package you want to take from unstable is installed through a NixOS module, you must use [[overlays]]:
</div>
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
{ config, pkgs, ... }:
{ config, pkgs, ... }:
Line 615: Line 625:
}
}
</syntaxhighlight>
</syntaxhighlight>
<div lang="en" dir="ltr" class="mw-content-ltr">
Note that this will rebuild all packages depending on the overlaid package, which may be a lot. Some modules offer a <code>services.foo.package</code> to change the actual derivation used by the module without and overlay, and without recompiling dependencies ([https://nixos.org/manual/nixos/stable/options.html#opt-services.gvfs.package example]).
Note that this will rebuild all packages depending on the overlaid package, which may be a lot. Some modules offer a <code>services.foo.package</code> to change the actual derivation used by the module without and overlay, and without recompiling dependencies ([https://nixos.org/manual/nixos/stable/options.html#opt-services.gvfs.package example]).
</div>
</div>
Line 620: Line 632:
<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
If you want to install unfree packages from unstable you need to also set allowUnfree by replacing the import statment above with:
If you want to install unfree packages from unstable you need to also set allowUnfree by replacing the import statment above with:
</div>
<syntaxhighlight lang="nix">
<syntaxhighlight lang="nix">
import <nixos-unstable> { config = { allowUnfree = true; }; }
import <nixos-unstable> { config = { allowUnfree = true; }; }
</syntaxhighlight>
</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 637: Line 650:
</div>  
</div>  


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">su nano /etc/nixos/configuration.nix</syntaxhighlight>
<syntaxhighlight lang="bash">su nano /etc/nixos/configuration.nix</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Add this line to your configuration file.
Add this line to your configuration file.
</div>
<syntaxhighlight lang="bash">boot.extraModulePackages = [ config.boot.kernelPackages.exfat-nofuse ];</syntaxhighlight>
<syntaxhighlight lang="bash">boot.extraModulePackages = [ config.boot.kernelPackages.exfat-nofuse ];</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 650: Line 662:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nixos-rebuild switch</syntaxhighlight>
<syntaxhighlight lang="bash">nixos-rebuild switch</syntaxhighlight>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 668: Line 678:
<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
=== What does it mean to say that NixOS is "immutable" ===
=== What does it mean to say that NixOS is "immutable" ===
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
Immutability is a property of data, in general, which means that the data cannot be modified after it is created. In the context of an operating system, it really means that certain parts of the system have this property. In the case of Nix and NixOS, that includes the Nix store, where files can be created but not modified after the time they are created. It does not apply to every part of the operating system, in that users can still modify their own files in their home directory, for example.
Immutability is a property of data, in general, which means that the data cannot be modified after it is created. In the context of an operating system, it really means that certain parts of the system have this property. In the case of Nix and NixOS, that includes the Nix store, where files can be created but not modified after the time they are created. It does not apply to every part of the operating system, in that users can still modify their own files in their home directory, for example.
</div>
</div>
Line 691: Line 704:
</div>
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
{{:FAQ/Libraries}}
{{:FAQ/Libraries}}
{{:FAQ/nix-env -iA}}
{{:FAQ/nix-env -iA}}
Line 697: Line 709:
{{:FAQ/notfound}}
{{:FAQ/notfound}}
<!-- Transclude subpages -->
<!-- Transclude subpages -->
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">

Revision as of 15:43, 10 October 2025

⚟︎
This article or section needs cleanup. Please edit the article, paying special attention to fixing any formatting issues, inconsistencies, grammar, or phrasing. Make sure to consult the Manual of Style for guidance.

为了避免重复回答那些经常被问到的问题以及处理新手常遇到的麻烦,这些问题被收录在这里。

为什么创建了一个新的维基?nixos.wiki 怎么了?

旧的 wiki(nixos.wiki)存在以下几个问题:

  • 许多组件(MediaWiki、PHP、ICU)严重过时。
    • MediaWiki 1.29(生命周期结束于 2018 年),当前版本为 1.35(生命周期结束于 2023 年 12 月)
    • PHP 7.3.33(生命周期结束于 2021 年 12 月)
    • ICU 64.2
  • Cloudflare 的 DDoS 防御有时会导致维基编辑失败。
  • 没有所见即所得(WYSIWYG)的编辑器。
  • 维基的基础设施本应在上线后公开,但最终未能公开。

我们曾通过多种渠道(电子邮件、Matrix)多次尝试解决这些问题,历时多年,但始终未能得到直接答复。最后一次联系是由 zimbatm 代表 NixOS 基金会与维护者沟通,询问关于新维基合作的可能性。答案是否定的。随着旧维基不断恶化且维护者未作回应,将内容分叉到一个新维基成为了唯一的解决方法。

另请参阅:

为什么 Nix 是用 C++ 编写的,而不是使用像 Haskell 这样的函数式语言?

主要是因为 Nix 旨在轻量级、易于学习且具有良好的可移植性(零依赖)。

如何保留构建时依赖/在离线状态下重新构建?

# /etc/nixos/configuration.nix
{ config, pkgs, lib, ... }:
{
  nix.settings = {
    keep-outputs = true;
    keep-derivations = true;
    # See https://nixos.org/manual/nix/stable/command-ref/conf-file.html
    # for a complete list of Nix configuration options.
  };
}

Check 'man configuration.nix' for these options. Rebuild for these options to take effect:

nixos-rebuild switch

List all store paths that form the system closure and realise them:

nix-store -qR $(nix-instantiate '<nixpkgs/nixos>' -A system) | xargs nix-store -r
warning: you did not specify `--add-root'; the result might be removed by the garbage collector

<build output and list of successfully realised paths>

Repeat for your user and further profiles:

nix-store -qR ~/.nix-profile | xargs nix-store -r

The warning can be ignored for profiles that are listed/linked in /nix/var/nix/profiles/ or one of its subdirectories.

Consult man pages of nix-store and nix-instantiate for further information.

为什么使用 <hash>-<name> 而不是 <name>-<hash>?

在少数需要深入查看 /nix/store 的情况下,将哈希值的前几位放在开头更方便记忆和使用。 也就是说,几乎可以仅通过哈希的前 4-5 个字符唯一地识别一个存储路径。 (这比先输入完整的包名再加上哈希的前几位要更高效。)

此外,由于开头部分长度一致,查看一系列软件包列表时在视觉上也更容易解析。

If you still wonder why, run ls -1 /nix/store | sort -R -t - -k 2 | less in your shell. (? unclear)

This is what might happen if you don't garbage collect frequently, or if you are testing compilation variants:

q0yi2nr8i60gm2zap46ryysydd2nhzhp-automake-1.11.1/
vbi4vwwidvd6kklq2kc0kx3nniwa3acl-automake-1.11.1/
wjgzir57hcbzrq3mcgxiwkyiqss3r4aq-automake-1.11.1/
1ch5549xnck37gg2w5fh1jgk6lkpq5mc-nixos-build-vms/
4cmjlxknzlvcdmfwj0ih0ggqsj5q73hb-nixos-build-vms/
7fv4kwi5wwwzd11ili3qwg28xrj8rxw2-nixos-build-vms/
8jij13smq9kdlqv96hm7y8xmbh2c54iy-nixos-build-vms/
j714mv53xi2j4ab4g2i08knqr137fd6l-nixos-build-vms/
xvs7y09jf7j48p6l0p87iypgpq470jqw-nixos-build-vms/

我更新了我的 channel后出现问题,如何回滚到之前的 channel?

查看可用的各代 channel:

nix-env --list-generations -p /nix/var/nix/profiles/per-user/root/channels
18   2014-04-17 09:16:28
19   2014-06-13 10:31:24 
20   2014-08-12 19:09:20   (current)
nix-env --list-generations -p /nix/var/nix/profiles/per-user/root/channels
18   2014-04-17 09:16:28
19   2014-06-13 10:31:24 
20   2014-08-12 19:09:20   (current)

回滚到上一代的方法如下:

nix-env --rollback -p /nix/var/nix/profiles/per-user/root/channels
switching from generation 20 to 19

To switch to a particular generation:

nix-env --switch-generation 18 -p /nix/var/nix/profiles/per-user/root/channels
switching from generation 20 to 18

I'm working on a new package, how can I build it without adding it to nixpkgs?

nix-build -E 'with import <nixpkgs> { }; callPackage ./mypackage.nix { }'

You can replace callPackage with callPackage_i686 to build the 32-bit version of your package on a 64-bit system if you want to test that.

How can I compile a package with debugging symbols included?

To build a package with -Og and -g, and without stripping debug symbols use:

nix-build -E 'with import <nixpkgs> { }; enableDebugging fooPackage'

See also Debug Symbols

How can I force a rebuild from source even without modifying the nix expression?

As root you can run nix-build with the --check flag:

sudo nix-build --check -A ncdu

How can I manage software with nix-env like with configuration.nix?

There are many ways, one is the following:

  1. Create a meta package called userPackages your ~/.config/nixpkgs/config.nix file with the packages you would like to have in your environment:

    with (import <nixpkgs> {});
    {
      packageOverrides = pkgs: with pkgs; {
        userPackages = buildEnv {
          inherit ((import <nixpkgs/nixos> {}).config.system.path)
          pathsToLink ignoreCollisions postBuild;
          extraOutputsToInstall = [ "man" ];
          name = "user-packages";
          paths = [ vim git wget ];
        };
      };
    }
    
  2. Install all specified packages using this command:

    nix-env -iA userPackages -f '<nixpkgs>'
    

Now you can add and remove packages from the paths list and rerun nix-env to update your user local packages.

Another way is using Home Manager.

I've downloaded a binary, but I can't run it, what can I do?

Binaries normally do not work out of the box when you download them because they normally just assume that libraries can be found in hardcoded paths such as /lib. However this assumption is incorrect on NixOS systems due to the inner workings of nix - there is no default path, everything gets set to the corresponding version on compile time.

If you are new to packaging proprietary software you should check out the Packaging Binaries Tutorial.

If you are in a hurry and just want to get shit running, continue reading:

You can use nix-ld to run compiled binaries. For example, if your binary needs zlib and openssl:

programs.nix-ld = {
  enable = true;
  libraries = [ pkgs.zlib pkgs.openssl ];
};

Log out and back in to apply the environment variables it sets, and you can then directly run the binary.

If you don't want to configure the list of libraries manually, a quick and dirty way to run nearly any precompiled binary is the following:

programs.nix-ld = {
  enable = true;
  libraries = pkgs.steam-run.args.multiPkgs pkgs;
};

This uses the libraries that are used by Steam to simulate a traditional Linux FHS environment to run games in. It's a big list that usually contains all the libraries your binary needs to run.

Another possibility is to use patchelf to set the library path and dynamic linker appropriately, since compiled binaries have hard-coded interpreter and require certain dynamic libraries.

# mybinaryprogram.nix
with import <nixpkgs> {}; 
stdenv.mkDerivation rec {
  name = "somename";
  buildInputs = [ makeWrapper ];
  buildPhase = "true";
  libPath = lib.makeLibraryPath with xlibs;[ libXrandr libXinerama libXcursor ];
  unpackPhase = "true";
  installPhase = ''
    mkdir -p $out/bin
    cp ${./mybinaryprogram} $out/bin/mybinaryprogram
  '';
  postFixup = ''
    patchelf \
      --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" \
      --set-rpath "${libPath}" \
      $out/bin/mybinaryprogram
  '';
}

This can be built with:

nix-build mybinaryprogram.nix

And run with:

./result/bin/mybinaryprogram

Another possibility is using a FHS-compatible Sandbox with buildFHSUserEnv

# fhsUser.nix
{ pkgs ? import <nixpkgs> {} }:
(pkgs.buildFHSUserEnv {
  name = "example-env";
  targetPkgs = pkgs: with pkgs; [
    coreutils
  ];
  multiPkgs = pkgs: with pkgs; [
    zlib
    xorg.libXxf86vm
    curl
    openal
    openssl_1_0_2
    xorg.libXext
    xorg.libX11
    xorg.libXrandr
    mesa_glu
  ];
  runScript = "bash";
}).env

the sandbox can be entered with

nix-shell fhsUser.nix

If your target application can't find shared libraries inside buildFHSUserEnv, you may run nix-de-generate for target application inside FHS, which will generate newenv.nix file, an nix-expression of buildFHSUserEnv with resolved dependencies for shared libraries.

What are channels and how do they get updated?

Main article: Channel branches

Nixpkgs is the git repository containing all packages and NixOS modules/expressions. Installing packages directly from Nixpkgs master branch is possible but a bit risky as git commits are merged into master before being heavily tested. That's where channels are useful.

A "channel" is a name for the latest "verified" git commits in Nixpkgs. Each channel has a different definition of what "verified" means. Each time a new git commit is verified, the channel declaring this verification gets updated. Contrary to an user of the git master branch, a channel user will benefit both from verified commits and binary packages from the binary cache.

Channels are reified as git branches in the nixpkgs repository and as disk images in the channels webpage. There are several channels, each with its own use case and verification phase:

  • nixos-unstable
    • description Use this when you want the latest package and module versions while still benefiting from the binary cache. You can use this channel on non-NixOS systems. This channel corresponds to NixOS’s main development branch, and may thus see radical changes between channel updates. This channel is not recommended for production systems.
    • definition this channel is updated depending on release.nix and release-lib.nix
  • nixos-unstable-small
    • description This channel is identical to nixos-unstable described above, except that this channel contains fewer binary packages. This means the channel gets updated faster than nixos-unstable (for instance, when a critical security patch is committed to NixOS’s source tree). However, the binary cache may contain less binary packages and thus using this channel may require building more packages from source than nixos-unstable. This channel is mostly intended for server environments and as such contains few GUI applications.
    • definition this channel is updated depending on release-small.nix and release-lib.nix
  • nixos-YY.MM (where YY is a 2-digit year and MM is a 2-digit month, such as nixos-17.03)
    • description These channels are called stable and only get conservative bug fixes and package upgrades. For instance, a channel update may cause the Linux kernel on your system to be upgraded from 3.4.66 to 3.4.67 (a minor bug fix), but not from 3.4.x to 3.11.x (a major change that has the potential to break things). Stable channels are generally maintained until the next stable branch is created.
    • definition this channel is updated depending on release.nix and release-lib.nix
  • nixos-YY.MM-small (where YY is a 2-digit year and MM is a 2-digit month, such as nixos-15.09-small)
    • description The difference between nixos-YY.MM-small and nixos-YY.MM is the same as the one between nixos-unstable-small and nixos-unstable (see above)

Channel update works as follows:

  1. Each channel has a particular job at hydra.nixos.org which must succeed:
  • For NixOS: the trunk-combined tested job, which contains some automated NixOS tests.
  • For nixos-small: the unstable-small tested job.
  • For nixpkgs: the trunk unstable job, which contains some critical release packages.


  1. Once the job succeeds at a particular nixpkgs commit, cache.nixos.org will download binaries from hydra.nixos.org.
  2. Once the above download completes, the channel updates.

You can checkout the nixpkgs git and reset it to a particular commit of a channel. This will not affect your access to the binary cache.

How do I know where's nixpkgs channel located and at which commit?

First echo $NIX_PATH to see where nix looks for the expressions. Note that nix-env uses ~/.nix-defexpr regardless of $NIX_PATH.

If you want to know where <nixpkgs> is located:

nix-instantiate --find-file nixpkgs

To know the commit, open the .version-suffix file in the nixpkgs location. The hash after the dot is the git commit.

Nixpkgs branches

Branches on the nixpkgs repo have a relationship with channels, but that relationship is not 1:1.

Some branches are reified as channels (e.g. the nixos-XX.YY branches, or nix(os|pkgs)-unstable), whereas others are the starting point for those branches (e.g. the master or release-XX.YY branches). For example:

  • When a change in master needs to be backported to the current NixOS release, it is cherry-picked into the current release-XX.YY branch
  • Hydra picks up this change, runs tests, and if those tests pass, updates the corresponding nixos-XX.YY branch, which is then reified as a channel.

So in short, the relase-XX.YY branches have not been run through Hydra yet, whereas the nixos-XX.YY ones have.

There's an updated version for $software on nixpkgs but not in channels, how can I use it?

You can jump the queue and use nix-shell with a NIX_PATH pointing to a tarball of the channel to get a shell for that software. Some building may occur. This will not work for system services.

NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs/archive/release-17.09.tar.gz nix-shell -p $software

How do I install a specific version of a package for build reproducibility etc.?

See FAQ/Pinning Nixpkgs and How to fetch Nixpkgs with an empty NIX PATH. Find the version of nixpkgs with the package version you want and pin nixpkgs to that. However, be aware that the pinning of a package of another nixpkgs version results in a much larger package size as not only the package itself but all dependencies (down to libc) have older versions.

if you just want the old version of the single package but with new dependencies it is often easier to copy the package description into your scope and add it to your configuration.nix via: mypackage-old = pkgs.callPackage ./mypackage-old.nix {};.You can try to build the package as described in the FAQ: building a single derivation.

An error occurs while fetching sources from an url, how do I fix it?

First try to update the local nixpkgs expressions with nix-channel --update (these describe where to download sources from and how to build them). Try your build again and the url might have already been correctly updated for the package in question. You can also subscribe the unstable channel (which includes the most up-to-date expressions) with nix-channel --add http://nixos.org/channels/nixpkgs-unstable, update and try the build again.

If that fails you can update the url in the nix expression yourself. Navigate to your channel's expressions and find the package in one of the subdirectories. Edit the respective default.nix file by altering the url and sha256. You can use nix-prefetch-url url to get the SHA-256 hash of source distributions.

If the shell complains that you do not have write privileges for the file system, you will have to enable them.

start a new shell with a private mount namespace (Linux-only)

sudo unshare -m bash

remount the filesystem with write privileges (as root)

mount -o remount,rw /nix/store

update the file

nano <PATH_TO_PACKAGE>/default.nix

exit to shell where /nix/store is still mounted read-only

exit

How do I know the sha256 to use with fetchgit, fetchsvn, fetchbzr or fetchcvs?

Install nix-prefetch-scripts and use the corresponding nix prefetch helper.

For instance to get the checksum of a git repository use:

nix-prefetch-git https://git.zx2c4.com/password-store

Or, use lib.fakeHash as the fetcher's hash argument, and attempt to build; Nix will tell you the actual and expected hash's mismatch, and you may copy the actual hash.

Should I use http://hydra.nixos.org/ as a binary cache?

No. As of 2017, all build artifacts are directly pushed to http://cache.nixos.org/ and are available there, therefore setting http://hydra.nixos.org/ as a binary cache no longer serves any function.

I'm trying to install NixOS but my WiFi isn't working and I don't have an ethernet port

Most phones will allow you to share your WiFi connection over USB. On Android you can enable this setting via Settings > Wireless & Networks / More ... > Tethering & portable hotspot > USB tethering. This should be enough to allow you to install NixOS, and then fix your WiFi. iPhones only let you tether using your data connection rather than WiFi.

It is also possible to build a custom NixOS installation ISO containing all the dependencies needed for an offline installation, but the default installation ISOs require internet connectivity.

For connecting to your WiFi, see NixOS_Installation_Guide#Wireless

How can I disable the binary cache and build everything locally?

Set the binary caches to an empty list: nix.binaryCaches = []; in configuration.nix or pass ad-hoc --option binary-caches '' as parameter to nix-build or its wrappers.

This is also useful to make simple configuration changes in NixOS (ex.: network related), when no network connectivity is available:

nixos-rebuild switch --option binary-caches ''

How do I enable sandboxed builds on non-NixOS?

Two options have to be added to make sandboxed builds work on Nix, build-use-sandbox and build-sandbox-paths:

# /etc/nix/nix.conf
build-use-sandbox = true
build-sandbox-paths = $(nix-store -qR $(nix-build '<nixpkgs>' -A bash) | xargs echo /bin/sh=$(nix-build '<nixpkgs>' -A bash)/bin/bash)

On NixOS set the following in configuration.nix:

nix.settings.sandbox = true;

See Nix package manager#Sandbox_builds for more details.

How can I install a package from unstable while remaining on the stable channel?

If you simply want to run a nix-shell with a package from unstable, you can run a command like the following:

nix-shell -I nixpkgs=channel:nixpkgs-unstable -p somepackage

It is possible to have multiple nix-channels simultaneously. To add the unstable channel with the specifier unstable,

sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos-unstable

After updating the channel

sudo nix-channel --update nixos-unstable

queries via nix-env will show packages from both stable and unstable. Use this to install unstable packages into your user environment. The following snippet shows how this can be done in configuration.nix.

{ config, pkgs, ... }:
let
  unstable = import <nixos-unstable> {};
in {
  environment.systemPackages = [ unstable.PACKAGE_NAME ];
}

This only changes what version of PACKAGE_NAME is available on $PATH. If the package you want to take from unstable is installed through a NixOS module, you must use overlays:

{ config, pkgs, ... }:
let
  unstable = import <nixos-unstable> {};
in {
  nixpkgs.overlays = [
    (self: super: {
       PACKAGE_NAME = unstable.PACKAGE_NAME;
    })
  ];
}

Note that this will rebuild all packages depending on the overlaid package, which may be a lot. Some modules offer a services.foo.package to change the actual derivation used by the module without and overlay, and without recompiling dependencies (example).

If you want to install unfree packages from unstable you need to also set allowUnfree by replacing the import statment above with:

import <nixos-unstable> { config = { allowUnfree = true; }; }

I'm unable to connect my USB HDD | External HDD is failing to mount automatically

Note: If you're using a kernel with at least version 5.6, you don't need to explicitly add this.

exfat is not supported in NixOS by default - since there are legality issues still with exFAT filesystem.

su nano /etc/nixos/configuration.nix

Add this line to your configuration file.

boot.extraModulePackages = [ config.boot.kernelPackages.exfat-nofuse ];

After saving the file rebuild NixOS:

nixos-rebuild switch

Restart NixOS.

What is the origin of the name "Nix"

The name Nix comes from the Dutch word niks which means nothing. It reflects the fact that Nix derivations do not have access to anything that has not been explicitly declared as an input.[1]

What does it mean to say that NixOS is "immutable"

Immutability is a property of data, in general, which means that the data cannot be modified after it is created. In the context of an operating system, it really means that certain parts of the system have this property. In the case of Nix and NixOS, that includes the Nix store, where files can be created but not modified after the time they are created. It does not apply to every part of the operating system, in that users can still modify their own files in their home directory, for example.

I'm getting ‘infinite recursion’ errors when trying to do something clever with imports

Evaluating the imports attribute of a NixOS module (such as configuration.nix) is a prerequisite for evaluating just about everything else, so trying anything clever with imports is a common source of infinite recursion (because the evaluator can't determine the values of packages and options without knowing what is imported, and can't determine what is imported without knowing the values of packages or options).

You should not try to conditionally import other modules based on other values. Make your imports unconditional, and make the modules that you're importing have conditional behavior based on the values of options.

If it helps, think of imports as akin to an #include directive in C.

(Note that none of this applies to the import built-in Nix language function, which is its own thing.)


I installed a library but my compiler is not finding it. Why?

With nix, only applications should be installed into profiles. Libraries are used using nix-shell. If you want to compile a piece of software that requires zlib (or openssl, sqlite etc.) and uses pkg-config to discover it, run

$ nix-shell -p gcc pkg-config zlib

to get into a shell with the appropriate environment variables set. In there, a configure script (with C Autotools, C++ CMake, Rust Cargo etc.) will work as expected.

This applies to other language environments too. In some cases the expressions to use are a bit different, e.g. because the interpreter needs to be wrapped to have some additional environment variables passed to it. The manual has a section on the subject.

Note that software built in such a shell may stop working after a garbage collection. This is because Nix only tracks dependencies of paths within the store. A clean build in a fresh shell can fix this one-off, but the long-term solution is to package the software in question rather than using a shell build regularly.

If you have a lot of dependencies, you may want to write a nix expression that includes your dependencies so that you can simply use nix-shell rather than writing out each dependency every time or keeping your development environment in your shell history. A minimal example looks like this:

# default.nix
with import <nixpkgs> {};
stdenv.mkDerivation {
    name = "dev-environment"; # Probably put a more meaningful name here
    buildInputs = [ pkg-config zlib ];
}

Why does it work like that?

This helps ensure purity of builds: on other distributions, the result of building a piece of software may depend on which other software you have installed. Nix attempts to avoid this to the greatest degree possible, which allows builds of a piece of software to be identical (in the ideal case) no matter where they're built, by requiring all dependencies to be declared.

Why not use nix-env -i hello?

nix-env -i hello is slower and tends to be less precise than nix-env -f '<nixpkgs>' -iA hello. This is because it will evaluate all of nixpkgs searching for packages with the name hello, and install the one determined to be the latest (which may not even be the one that you want). Meanwhile, with -A, nix-env will evaluate only the given attribute in nixpkgs. This will be significantly faster, consume significantly less memory, and more likely get you what you want.

nix-env -u has the same problem, searching for all the packages in the user environment by name and upgrading them. This may lead to unwanted major-version upgrades like JDK 8 → JDK 9. If you want to have a declarative user environment, you may wish to use Home Manager. It is also possible to home-bake a pure nix solution like LnL's. With this setup, you can update your packages by simply running nix-rebuild.

<onlyinclude>

⚠︎
Warning: system.stateVersion should never be updated

Why am I told not to update[2] system.stateVersion?

Since it is not clearly codified what system.stateVersion should be used for, and it is used for a great many different things in practice[3], there is no practical way to ensure that changing it is ever safe.

The consequences of changing its value range from none at all, to complete destruction of data written by specific software.

How do I update NixOS, if changing system.stateVersion does not do that?

See Updating nixos.

Why does system.stateVersion look like a NixOS version?

This is because it notes down the version of NixOS you first installed with a given configuration. It does not mean that you should update it.

When can I update system.stateVersion safely?

Currently, you cannot update it safely without a complete understanding of all NixOS modules you are using, directly or indirectly.

Only when the NixOS release notes say that it can be changed, should it be changed.

Is it ok to leave system.stateVersion at a very old version?

The NixOS module authors are aware of their use of the setting, and must ensure that old versions continue to work. Whether and how this is sustainable is an upstream issue; Users should not update the setting unless instructed otherwise.

What even is system.stateVersion for, if it is just an unchanging string?

Generally, it is used to inform NixOS what versions of packages you might have previously installed. This is used to ensure correct data migration for certain packages[2]. Since NixOS configurations are stateless, and therefore cannot know what data may already be on your system, there is no other way to identify this.

system.stateVersion in practice is also used for other potential issues that stem from version upgrades[3] - it is somewhat controversial what and what not it should be used for, resulting in many different use cases. The current and historic lack of a clear definition of what it does is part of why it cannot be updated.

References

</noinclude>

I cannot find $package when running nix-env -qaP even with channels configured

Not all packages are listed. Packages may not be listed because:

  • the package is unfree, like e.g. unrar and teamspeak_client; see Unfree software for more information
  • the package is part of an attribute set and nix-env doesn't recurse into this set (see pkgs.recurseIntoAttrs), use nix-env -qaP -A haskellPackages for listing these entries


References