Jump to content

Cheatsheet: Difference between revisions

imported>Mib
m (Fix indentation in code example)
 
(7 intermediate revisions by 3 users not shown)
Line 23: Line 23:
</syntaxHighlight>
</syntaxHighlight>


==== Adding files to the store ====
==== Get store path for a package from the Flake input ====
When packages are managed using [[Flakes]], store paths to them can be retrieved using <code>nix eval --inputs-from</code>, like this:<syntaxhighlight lang="shell">
$ nix eval --inputs-from "$flake_path" --raw "$input#$package"
</syntaxhighlight>For instance, when packages are managed using [[Home Manager]] using standard configuration, store path to the [[Git]] package can be retrieved using this command:<syntaxhighlight lang="shell">
$ nix eval --inputs-from ~/.config/home-manager --raw nixpkgs#git
</syntaxhighlight>


=== Add files to the store ===
It is sometimes necessary to add files to the store manually.
It is sometimes necessary to add files to the store manually.
This is particularly the case with packages that cannot be downloaded automatically,
This is particularly the case with packages that cannot be downloaded automatically,
Line 34: Line 40:
</syntaxHighlight>
</syntaxHighlight>


Unfortunately, `nix-store` will try to load the entire file into memory,
Unfortunately, <code>nix-store</code> will try to load the entire file into memory,
which will fail if the file size exceeds available memory.
which will fail if the file size exceeds available memory.
If we have root access, we can copy the file to the store ourselves:
If we have root access, we can copy the file to the store ourselves:
Line 55: Line 61:
</syntaxHighlight>
</syntaxHighlight>


=== Build nixos from nixpkgs repo ===
=== Build NixOS from nixpkgs repo ===


The following snippet will build the system from a git checkout:
The following snippet will build the system from a git checkout:
Line 63: Line 69:
</syntaxHighlight>
</syntaxHighlight>


This method can be used when testing nixos services for a pull request to nixpkgs.
This method can be used when testing NixOS services for a pull request to nixpkgs.


Building nixos from a git is an alternative to using nix channels and set up permanent following this [https://web.archive.org/web/20160327190212/http://anderspapitto.com/posts/2015-11-01-nixos-with-local-nixpkgs-checkout.html blog article].
Building NixOS from a git is an alternative to using nix channels and set up permanent following this [https://web.archive.org/web/20160327190212/http://anderspapitto.com/posts/2015-11-01-nixos-with-local-nixpkgs-checkout.html blog article].
It has a couple of advantages over nixpkgs as it allows back-porting of packages/changes to stable versions
It has a couple of advantages over nixpkgs as it allows back-porting of packages/changes to stable versions
as well as applying customization.
as well as applying customization.
Line 77: Line 83:
=== Evaluate a NixOS configuration without building ===
=== Evaluate a NixOS configuration without building ===


If you only want to evaluate `configuration.nix` without building (e.g. to syntax-check or see if you are using module options correctly), you can use:
If you only want to evaluate <code>configuration.nix</code> without building (e.g. to syntax-check or see if you are using module options correctly), you can use:


<syntaxHighlight lang="console">
<syntaxHighlight lang="console">
Line 83: Line 89:
</syntaxHighlight>
</syntaxHighlight>


This creates the `.drv` file that `nixos-rebuild build` would build.
This creates the <code>.drv</code> file that <code>nixos-rebuild build</code> would build.
 
=== Explore a NixOS configuration in the REPL ===
If you want to see what ''value'' a NixOS option takes without building, as opposed to merely checking that all options work, you can run:
<syntaxhighlight lang="console">
$ nix repl --file '<nixpkgs/nixos>'
Welcome to Nix 2.18.2. Type :? for help.
 
Loading installable ''...
Added 6 variables.
nix-repl> config.environment.shells  # for example
[ "/run/current-system/sw/bin/zsh" ... ]
 
# Equivalently, if starting from an existing REPL:
nix-repl> :l <nixpkgs/nixos>
Added 6 variables.
 
nix-repl> config.environment.shells
</syntaxhighlight>
 
This can be helpful if your configuration is spread across multiple modules, or if you import modules from external sources, or if NixOS has defaults and you want to know whether a default is being used or extended in your configuration, or a variety of other cases in which you might want the computer to tell you what the end result of all your Nixing is going to be before you switch to it.
 
You can do this with configuration files other than the one installed in <code>/etc/nixos</code>, too:
 
<pre>
nix-repl> :a import <nixpkgs/nixos> { configuration = /path/to/config.nix; }
</pre>


=== Manually switching a NixOS system to a certain version of system closure ===
=== Manually switching a NixOS system to a certain version of system closure ===
Line 136: Line 168:
where <code>-I nixpkgs=/path/to/nixpkgs</code> is optionally depending whether the vm should be build from git checkout or a channel.
where <code>-I nixpkgs=/path/to/nixpkgs</code> is optionally depending whether the vm should be build from git checkout or a channel.


On non-nixos (linux) systems the following command can be used instead:
On non-NixOS (linux) systems the following command can be used instead:


<syntaxHighlight lang="console">
<syntaxHighlight lang="console">
Line 156: Line 188:
</syntaxHighlight>
</syntaxHighlight>


Don't forget that by default nixos comes with a firewall enabled:
Don't forget that by default NixOS comes with a firewall enabled:


<syntaxHighlight lang="nix">
<syntaxHighlight lang="nix">
Line 166: Line 198:
=== Reuse a package as a build environment ===
=== Reuse a package as a build environment ===
As packages already contains all build dependencies, they can be reused to a build environment quickly.
As packages already contains all build dependencies, they can be reused to a build environment quickly.
In the following a setup for the cmake-based project [bcc](https://github.com/iovisor/bcc) is shown.
In the following a setup for the cmake-based project [https://github.com/iovisor/bcc bcc] is shown.
After obtaining the source:
After obtaining the source:


Line 184: Line 216:
</syntaxHighlight>
</syntaxHighlight>


To initiate the build environment run `nix-shell` in the project root directory
To initiate the build environment run <code>nix-shell</code> in the project root directory


<syntaxHighlight lang="console">
<syntaxHighlight lang="console">
Line 204: Line 236:
=== Evaluate packages for a different platform ===
=== Evaluate packages for a different platform ===


Sometimes you want to check whether a change to a package (such as adding a new dependency) would evaluate even on a different type of system. For example, you may want to check on `x86_64-linux` whether a package evaluates for `x86_64-darwin` or `aarch64-linux`.
Sometimes you want to check whether a change to a package (such as adding a new dependency) would evaluate even on a different type of system. For example, you may want to check on <code>x86_64-linux</code> whether a package evaluates for <code>x86_64-darwin</code> or <code>aarch64-linux</code>.


Use the `system` argument:
Use the <code>system</code> argument:


<syntaxHighlight lang="console">
<syntaxHighlight lang="console">
Line 236: Line 268:
</syntaxHighlight>
</syntaxHighlight>


and the following in `configuration.nix`:
and the following in <code>configuration.nix</code>:


<syntaxHighlight lang="nix">
<syntaxHighlight lang="nix">
Line 330: Line 362:
== See also ==
== See also ==


- [[Garbage Collection]]
* [[Garbage Collection]]
- [[NFS#Nix_store_on_NFS|Nix store on NFS]]
* [[NFS#Nix_store_on_NFS|Nix store on NFS]]


[[Category:Cookbook]]
[[Category:Cookbook]]
[[Category:Software]]
[[Category:Software]]
6

edits