Flakes/ja: Difference between revisions

'''Nix flakes''' は [https://nixos.org/manual/nix/stable/contributing/experimental-Features.html 試験的な機能] で Nix 2.4 で導入されました。 ([https://nixos.org/manual/nix/unstable/release-notes/rl-2.4.html リリースノートを参照してください])。

Nix flakesはNixのプロジェクトに一定の構造を強制し、ロックファイルを用いて依存するプロジェクトのバージョンを指定することでより便利に再現可能なNix式を記述できるようにします。

<syntaxhighlight lang="shell">

  --experimental-features 'nix-command flakes'

</syntaxhighlight>

<syntaxHighlight lang=nix>

   nix.settings.experimental-features = [ "nix-command" "flakes" ];

</syntaxHighlight>

<syntaxhighlight lang="nix">

   nix.settings.experimental-features = [ "nix-command" "flakes" ];

</syntaxhighlight>

<syntaxHighlight lang=text>

experimental-features = nix-command flakes

</syntaxHighlight>

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

</div>

<syntaxHighlight lang=text>

nix flake init

</syntaxHighlight>

== Flake schema ==

<code>inputs.nixpkgs.url = "github:NixOS/nixpkgs/<branch name>";</code>

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

</div>

<code>inputs.hyprland.url = "github:hyprwm/Hyprland";</code>

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

If you want to make Hyprland follow the nixpkgs input to avoid having multiple versions of nixpkgs, this can be done using the following code:

</div>

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

</div>

inputs = {

   nixpkgs.url = "github:NixOS/nixpkgs/<branch name>";

};

</syntaxhighlight>

</div>

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

This is described in the nix package manager [https://github.com/NixOS/nix/blob/master/src/nix/flake-check.md src/nix/flake-check.md].

</div>

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

* <code><system></code> is something like "x86_64-linux", "aarch64-linux", "i686-linux", "x86_64-darwin"

* <code><name></code> is an attribute name like "hello".

* <code><flake></code> is a flake name like "nixpkgs".

* <code><store-path></code> is a <code>/nix/store..</code> path

</div>

<syntaxHighlight lang=nix>

{ self, ... }@inputs:

   # Executed by `nix run . -- <args?>`

   apps."<system>".default = { type = "app"; program = "..."; };

   formatter."<system>" = derivation;

   # Used for nixpkgs packages, also accessible via `nix build .#<name>`

}

</syntaxHighlight>

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

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

==== nix run ====

When output <code>apps.<system>.myapp</code> is not defined, <code>nix run myapp</code> runs <code><packages or legacyPackages.<system>.myapp>/bin/<myapp.meta.mainProgram or myapp.pname or myapp.name (the non-version part)></code>

</div>

</div>

<syntaxHighlight lang=nix>

(import (

}).defaultNix

</syntaxHighlight>

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

</div>

<syntaxHighlight lang=nix>

   inputs.flake-compat = {

   };

</syntaxHighlight>

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

</div>

<syntaxhighlight lang="nix">

(import (

) { src = ./.; }).defaultNix

</syntaxhighlight>

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

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

* fetchurl and fetchtar [https://github.com/NixOS/nix/blob/36c4d6f59247826dde32ad2e6b5a9471a9a1c911/src/libexpr/primops/fetchTree.cc#L201 require] a sha256 argument to be considered pure.

* builtins.currentSystem is non-hermetic and impure. This can usually be avoided by passing the system (i.e., x86_64-linux) explicitly to derivations requiring it.

* Imports from channels like <code><nixpkgs></code> can be made pure by instead importing from the <code>output</code> function in <code>flake.nix</code>, where the arguments provide the store path to the flake's inputs:

</div>

<syntaxhighlight lang="nix">

  outputs = { self, nixpkgs, ... }:

   };

</syntaxhighlight>

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

</div>

<syntaxhighlight lang="nix">

{

}

</syntaxhighlight>

If you want to pass on the flake inputs to external configuration files, you can use the <code>specialArgs</code> attribute:

<syntaxhighlight lang="nix">

{

   inputs.nixpkgs.url = github:NixOS/nixpkgs/nixos-unstable;

   inputs.home-manager.url = github:nix-community/home-manager;

     nixosConfigurations.fnord = nixpkgs.lib.nixosSystem {

       specialArgs = { inherit inputs; };

}

</syntaxhighlight>

Then, you can access the flake inputs from the file <code>configuration.nix</code> like this:

<syntaxhighlight lang="nix">

{ config, lib, inputs, ... }: {

}

</syntaxhighlight>

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

</div>

<syntaxhighlight lang="console">

$ sudo nixos-rebuild switch --flake .

</syntaxhighlight>

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

</div>

<syntaxhighlight lang="console">

$ sudo nixos-rebuild switch --flake /etc/nixos#joes-desktop

</syntaxhighlight>

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

To switch a remote host you can use:

<syntaxhighlight lang="bash">

$ nixos-rebuild --flake .#mymachine \

   switch

</syntaxhighlight>

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

</div>

<syntaxhighlight lang="nix">

{ inputs, ... }:

}

</syntaxhighlight>

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

</div>

<syntaxHighlight lang=nix>

   nix.registry = {

   };

</syntaxHighlight>

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

</div>

<syntaxhighlight lang="nix">

{

pkgs.mkShell {

   packages = [ pkgs.nixfmt ];

     # ...

   '';

}

</syntaxhighlight>

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

</div>

<syntaxhighlight lang="nix">

{

   inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";

     { nixpkgs, ... }:

     {

         This example assumes your system is x86_64-linux

         change as neccesary

}

</syntaxhighlight>

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

</div>

https://docs.cachix.org/pushing#flakes

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

</div>

<syntaxHighlight lang=console>

$ nix build .#hello

</syntaxHighlight>

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

</div>

<syntaxhighlight lang="console">

nix build '.?submodules=1#hello'

</syntaxhighlight>

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

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

A NixOS config flake could be as follows:

<syntaxhighlight lang="nix">

{

   description = "NixOS configuration with two or more channels";

     nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11";

     nixpkgs-unstable.url = "github:NixOS/nixpkgs/nixos-unstable";

   };

     { nixpkgs, nixpkgs-unstable, ... }:

     {

}

</syntaxhighlight>

<syntaxhighlight lang="nix">

# NixOS configuration.nix, can now use "pkgs.package" or "pkgs.unstable.package"

   # ...

}

</div>

<syntaxhighlight lang="nix">

pkgs = import nixpkgs { system = "x86_64-linux"; overlays = [ /*the overlay in question*/ ]; };

</syntaxhighlight>

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

</div>

<syntaxhighlight lang="text">

$ nix repl

nix-repl> :lf /path/to/flake

Added 18 variables.

nix-repl> nixosConfigurations.myHost.config.networking.hostName

"myHost"

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

</div>

nix.nixPath = let path = toString ./.; in [ "repl=${path}/repl.nix" "nixpkgs=${inputs.nixpkgs}" ];

</syntaxHighlight>

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

</div>

<syntaxHighlight lang=nix>

let

// flake.nixosConfigurations

</syntaxHighlight>

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

</div>

<syntaxHighlight lang=bash>

source /etc/set-environment && nix repl $(echo $NIX_PATH | perl -pe 's|.*(/nix/store/.*-source/repl.nix).*|\1|')</syntaxHighlight>

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

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

An alternative approach to the above shell alias is omitting <code>repl</code> from <code>nix.nixPath</code> and creating a shell script:

<syntaxHighlight lang=nix>

nix.nixPath = [ "nixpkgs=${inputs.nixpkgs}" ];

];

</syntaxHighlight>

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

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

== Development tricks ==

=== Build a package added in a PR ===

<syntaxHighlight>

nix build github:nixos/nixpkgs?ref=pull/<PR_NUMBER>/head#<PACKAGE>

</syntaxHighlight>

this allows building a package that has not yet been added to nixpkgs.

</div>

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

note that this will download a full source tarball of nixpkgs.  if you already have a local clone, using that may be faster due to delta compression:

<syntaxHighlight>

git fetch upstream pull/<PR_NUMBER>/head && git checkout FETCH_HEAD && nix build .#PACKAGE

</syntaxHighlight>

this allows building a package that has not yet been added to nixpkgs.

=== How to add a file locally in git but not include it in commits ===

</div>

</div>

<syntaxHighlight>

git add --intent-to-add extra/flake.nix

git update-index --skip-worktree --assume-unchanged extra/flake.nix

</syntaxHighlight>

</div>

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

One common pain point with using Nix as a development environment is the need to completely rebuild dependencies and re-enter the dev shell every time they are updated. The <code>nix develop --redirect <flake> <directory></code> command allows you to provide a mutable dependency to your shell as if it were built by Nix.

</div>

</div>

<syntaxHighlight lang=bash>

cd ~/libdep-src-checkout/

installPhase # install it like nix does

</syntaxHighlight>

Now that you've built the dependency, <code>consumexe</code> can take it as an input. '''In another terminal''':

<syntaxHighlight lang=bash>

cd ~/consumexe-src-checkout/

# Output should show ~/libdep-src-checkout/ so you know it worked

</syntaxHighlight>

If Nix warns you that your redirected flake isn't actually used as an input to the evaluated flake, try using the <code>--inputs-from .</code> flag. If all worked well you should be able to <code>buildPhase && installPhase</code> when the dependency changes and rebuild your consumer with the new version ''without'' exiting the development shell.

</div>

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

* [https://nix.dev/concepts/flakes Flakes] - nix.dev

* [https://github.com/NixOS/rfcs/pull/49 RFC 49] (2019) - Original flakes specification

* [https://jade.fyi/blog/flakes-arent-real/ Flakes aren't real and can't hurt you] (Jade Lovelace, 2024)

* [https://github.com/ryan4yin/nixos-and-flakes-book NixOS & Flakes Book](Ryan4yin, 2023) - 🛠️ ❤️ An unofficial NixOS & Flakes book for beginners.

* [https://xeiaso.net/blog/nix-flakes-1-2022-02-21 Nix Flakes: an Introduction] (Xe Iaso, 2022)

* [https://serokell.io/blog/practical-nix-flakes Practical Nix Flakes] (Alexander Bantyev, 2021) - Intro article on working with Nix and Flakes

* [https://www.tweag.io/blog/2020-05-25-flakes/ Nix Flakes, Part 1: An introduction and tutorial] (Eelco Dolstra, 2020)

* [https://www.tweag.io/blog/2020-06-25-eval-cache/ Nix Flakes, Part 2: Evaluation caching] (Eelco Dolstra, 2020)

* [https://www.tweag.io/blog/2020-07-31-nixos-flakes/ Nix Flakes, Part 3: Managing NixOS systems] (Eelco Dolstra, 2020)

* [https://nixos.org/manual/nix/unstable/command-ref/new-cli/nix3-flake.html Nix flake command reference manual] - Many additional details about flakes, and their parts.

* [https://www.youtube.com/watch?v=QXUlhnhuRX4&list=PLgknCdxP89RcGPTjngfNR9WmBgvD_xW0l Nix flakes 101: Introduction to nix flakes] (Jörg Thalheim, 2020)

* [https://github.com/NixOS/nix/blob/master/src/nix/flake.md spec describing flake inputs in more detail]

* [https://github.com/numtide/flake-utils flake-utils: Library to avoid some boiler-code when writing flakes]

* [https://zimbatm.com/NixFlakes/#direnv-integration zimbat's direnv article]

* [https://github.com/nix-community/todomvc-nix building Rust and Haskell flakes]

</div>

[[Category:Software]]

[[Category:Nix]]

[[Category:Flakes]]