Jump to content

Cheatsheet: Difference between revisions

Cheatsheet (view source)

Revision as of 18:45, 15 June 2024

1,993 bytes added ,  15 June
→‎Explore a NixOS configuration in the REPL
VisualWikitext
imported>Fricklerhandwerk
(move comparison table to Ubuntu vs. NixOS)
 
(13 intermediate revisions by 8 users not shown)
Line 1: Line 1:
=== Comparison of secret managing schemes ===
== A NixOS cheat sheet and comparison to Ubuntu ==
 
[[Ubuntu_vs._NixOS|Ubuntu vs. NixOS]] provides a table mapping of common administrative tasks and their commands in Ubuntu to similar capabilities in NixOS.
Manage [https://nixos.wiki/wiki/Comparison_of_secret_managing_schemes secrets] in your (system) configuration. That page tries to give an overview of different schemes that can be used and outlines the aims, requirements and implications of each.


== Working with the nix store ==
== Working with the nix store ==
Line 9: Line 8:
<syntaxHighlight lang="console">
<syntaxHighlight lang="console">
$ nix repl
$ nix repl
nix-repl> :l <nixpkgs>
nix-repl> :l <nixpkgs>  
Added 7486 variables.
Added 7486 variables.
nix-repl> "${xorg.libXtst}"
nix-repl> "${xorg.libXtst}"
"/nix/store/nlpnx21yjdjx2ii7ln4kcmbm0x1vy7w9-libXtst-1.2.3"
"/nix/store/nlpnx21yjdjx2ii7ln4kcmbm0x1vy7w9-libXtst-1.2.3"
nix-repl> :lf ./configuration.nix # as flakes way for a local file
# load nixos configuration from a nix file
$ nix repl --file '<nixpkgs/nixos>' -I nixos-config=./configuration.nix


$ nix-build '<nixpkgs>' --no-build-output -A xorg.libXtst
$ nix-build '<nixpkgs>' --no-build-output -A xorg.libXtst
Line 18: 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 29: 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 50: 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 58: 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 72: 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 78: 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 131: 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 151: 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 161: 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 179: 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 199: 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 `x68_64-linux` whether a package evaluates for `x68_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 231: 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 238: Line 275:
   allowUnfree = true;
   allowUnfree = true;


# Create an alias for the unstable channel
  # Create an alias for the unstable channel
 
  packageOverrides = pkgs: {
packageOverrides = pkgs: {
    unstable = import <nixos-unstable> { # pass the nixpkgs config to the unstable alias # to ensure `allowUnfree = true;` is propagated:
unstable = import <nixos-unstable> { # pass the nixpkgs config to the unstable alias # to ensure `allowUnfree = true;` is propagated:
      config = config.nixpkgs.config;
config = config.nixpkgs.config;
    };
};
  };
};
};
};
</syntaxHighlight>
</syntaxHighlight>
Line 326: 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]]
Rhendric
6

edits

Retrieved from "https://wiki.nixos.org/wiki/Special:MobileDiff/578...13183"