Nix 2.24 released

Announcements Nix Releases
1

Hi,

I’m pleased to announce the availability of Nix 2.24.0. It is available from https://releases.nixos.org/?prefix=nix/nix-2.24.0/.

The most important changes are as follows:

Significant changes

  • Harden user sandboxing

    The build directory has been hardened against interference with the outside world by nesting it inside another directory owned by (and only readable by) the daemon user.

    This is a low severity security fix, CVE-2024-38531.

    Credit: @alois31, Linus Heckemann (@lheckemann)
    Co-authors: @edolstra

  • nix-shell <directory> looks for shell.nix #496 #2279 #4529 #5431 #11053 #11057

    nix-shell $x now looks for $x/shell.nix when $x resolves to a directory.

    Although this might be seen as a breaking change, its primarily interactive usage makes it a minor issue. This adjustment addresses a commonly reported problem.

    This also applies to nix-shell shebang scripts. Consider the following example:

    #!/usr/bin/env nix-shell
#!nix-shell -i bash

    This will now load shell.nix from the script’s directory, if it exists; default.nix otherwise.

    The old behavior can be opted into by setting the option nix-shell-always-looks-for-shell-nix to false.

    Author: Robert Hensing (@roberth)

  • nix-repl’s :doc shows documentation comments #3904 #10771 #1652 #9054 #11072

    nix repl has a :doc command that previously only rendered documentation for internally defined functions. This feature has been extended to also render function documentation comments, in accordance with RFC 145.

    Example:

    nix-repl> :doc lib.toFunction
Function toFunction
    … defined at /home/user/h/nixpkgs/lib/trivial.nix:1072:5

    Turns any non-callable values into constant functions. Returns
    callable values as is.

Inputs

    v

      : Any value

Examples

    :::{.example}

## lib.trivial.toFunction usage example

      | nix-repl> lib.toFunction 1 2
      | 1
      |
      | nix-repl> lib.toFunction (x: x + 1) 2
      | 3

    :::

    Known limitations:

    • It does not render documentation for “formals”, such as { /** the value to return */ x, ... }: x.
    • Some extensions to markdown are not yet supported, as you can see in the example above.

    We’d like to acknowledge Yingchi Long (@inclyc) for proposing a proof of concept for this functionality in #9054, as well as @sternenseemann and Johannes Kirschbauer (@hsjobeki) for their contributions, proposals, and their work on RFC 145.

    Author: Robert Hensing (@roberth)

Other changes

  • Solve cached failure of attribute X #9165 #10513 #10564

    This eliminates all “cached failure of attribute X” messages by forcing evaluation of the original value when needed to show the exception to the user. This enhancement improves error reporting by providing the underlying message and stack trace.

    Author: Eelco Dolstra (@edolstra)

  • Run the flake regressions test suite #10603

    This update introduces a GitHub action to run a subset of the flake regressions test suite, which includes 259 flakes with their expected evaluation results. Currently, the action runs the first 25 flakes due to the full test suite’s extensive runtime. A manually triggered action may be implemented later to run the entire test suite.

    Author: Eelco Dolstra (@edolstra)

  • Support unit prefixes in configuration settings #10668

    Configuration settings in Nix now support unit prefixes, allowing for more intuitive and readable configurations. For example, you can now specify --min-free 1G to set the minimum free space to 1 gigabyte.

    This enhancement was extracted from #7851 and is also useful for PR #10661.

    Author: Eelco Dolstra (@edolstra)

  • nix build: show all FOD errors with --keep-going #10734

    The nix build command has been updated to improve the behavior of the [--keep-going] flag. Now, when --keep-going is used, all hash-mismatch errors of failing fixed-output derivations (FODs) are displayed, similar to the behavior for other build failures. This enhancement ensures that all relevant build errors are shown, making it easier for users to update multiple derivations at once or to diagnose and fix issues.

    Author: Jörg Thalheim (@Mic92), Maximilian Bosch (@Ma27)

    --keep-going

  • Build with Meson #2503 #10378 #10855 #10904 #10908 #10914 #10933 #10936 #10954 #10955 #10963 #10967 #10973 #11034 #11054 #11055 #11060 #11064 #11155

    These changes aim to replace the use of autotools and make with Meson for building various components of Nix. Additionally, each library is built in its own derivation, leveraging Meson’s “subprojects” feature to allow a single development shell for building all libraries while also supporting separate builds. This approach aims to improve productivity and build modularity, compared to both make and a monolithic Meson-based derivation.

    Special thanks to everyone who has contributed to the Meson port, particularly @p01arst0rm and @Qyriad.

    Authors: John Ericson (@Ericson2314), Tom Bereknyei, Théophane Hufschmitt (@thufschmitt), Valentin Gagarin (@fricklerhandwerk), Robert Hensing (@roberth)
    Co-authors: @p01arst0rm, @Qyriad

  • Evaluation cache: fix cache regressions #10570 #11086

    This update addresses two bugs in the evaluation cache system:

    1. Regression in #10570: The evaluation cache was not being persisted in nix develop.
    2. Nix could sometimes try to commit the evaluation cache SQLite transaction without there being an active transaction, resulting in non-error errors being printed.

    Author: Lexi Mattick (@kognise)

  • Introduce libnixflake #9063

    A new library, libnixflake, has been introduced to better separate the Flakes layer within Nix. This change refactors the codebase to encapsulate Flakes-specific functionality within its own library.

    See the commits in the pull request for detailed changes, with the only significant code modifications happening in the initial commit.

    This change was alluded to in RFC 134 and is a step towards a more modular and maintainable codebase.

    Author: John Ericson (@Ericson2314)

  • CLI options --arg-from-file and --arg-from-stdin #9913

  • The --debugger now prints source location information, instead of the
    pointers of source location information. Before:

    nix-repl> :bt
0: while evaluating the attribute 'python311.pythonForBuild.pkgs'
0x600001522598

    After:

    0: while evaluating the attribute 'python311.pythonForBuild.pkgs'
/nix/store/hg65h51xnp74ikahns9hyf3py5mlbbqq-source/overrides/default.nix:132:27

   131|
   132|       bootstrappingBase = pkgs.${self.python.pythonAttr}.pythonForBuild.pkgs;
      |                           ^
   133|     in

  • Stop vendoring toml11

    We don’t apply any patches to it, and vendoring it locks users into
    bugs (it hasn’t been updated since its introduction in late 2021).

    Author: Winter (@winterqt)

  • Rename hash format base32 to nix32 #8678

    Hash format base32 was renamed to nix32 since it used a special nix-specific character set for
    Base32.

    Deprecation: Use nix32 instead of base32 as toHashFormat

    For the builtin convertHash, the toHashFormat parameter now accepts the same hash formats as the --to/--from
    parameters of the nix hash conert command: "base16", "nix32", "base64", and "sri". The former "base32" value
    remains as a deprecated alias for "nix32". Please convert your code from:

    builtins.convertHash { inherit hash hashAlgo; toHashFormat = "base32";}

    to

    builtins.convertHash { inherit hash hashAlgo; toHashFormat = "nix32";}

  • Add pipe-operators experimental feature #11131

    This is a draft implementation of RFC 0148.

    The pipe-operators experimental feature adds <| and |> operators to the Nix language. a |> b is equivalent to the function application b a, and a <| b is equivalent to the function application a b.

    For example:

    nix-repl> 1 |> builtins.add 2 |> builtins.mul 3
9

nix-repl> builtins.add 1 <| builtins.mul 2 <| 3
7

    <| and |> are right and left associative, respectively, and have lower precedence than any other operator. These properties may change in future releases.

    See the RFC for more examples and rationale.

  • nix-shell shebang uses relative path #4232 #5088 #11058

    Relative path literals in nix-shell shebang scripts’ options are now resolved relative to the script’s location. Previously they were resolved relative to the current working directory.

    For example, consider the following script in ~/myproject/say-hi:

    #!/usr/bin/env nix-shell
#!nix-shell --expr 'import ./shell.nix'
#!nix-shell --arg toolset './greeting-tools.nix'
#!nix-shell -i bash
hello

    Older versions of nix-shell would resolve shell.nix relative to the current working directory, such as the user’s home directory in this example:

    [hostname:~]$ ./myproject/say-hi
error:
       … while calling the 'import' builtin
         at «string»:1:2:
            1| (import ./shell.nix)
             |  ^

       error: path '/home/user/shell.nix' does not exist

    Since this release, nix-shell resolves shell.nix relative to the script’s location, and ~/myproject/shell.nix is used.

    $ ./myproject/say-hi
Hello, world!

    Opt-out

    This is technically a breaking change, so we have added an option so you can adapt independently of your Nix update. The old behavior can be opted into by setting the option nix-shell-shebang-arguments-relative-to-script to false. This option will be removed in a future release.

    Author: Robert Hensing (@roberth)

  • Improve handling of tarballs that don’t consist of a single top-level directory #11195

    In previous Nix releases, the tarball fetcher (used by builtins.fetchTarball) erroneously merged top-level directories into a single directory, and silently discarded top-level files that are not directories. This is no longer the case. The new behaviour is that only if the tarball consists of a single directory, the top-level path component of the files in the tarball is removed (similar to tar’s --strip-components=1).

    Author: Eelco Dolstra (@edolstra)

  • Improve handling of tarballs that don’t consist of a single top-level directory #11195

    In previous Nix releases, the tarball fetcher (used by builtins.fetchTarball) erroneously merged top-level directories into a single directory, and silently discarded top-level files that are not directories. This is no longer the case.

    Author: Eelco Dolstra (@edolstra)

  • Setting to warn about large paths #10778

    Nix can now warn when evaluation of a Nix expression causes a large
    path to be copied to the Nix store. The threshold for this warning can
    be configured using the warn-large-path-threshold setting,
    e.g. --warn-large-path-threshold 100M.

Contributors

This release was made possible by the following 43 contributors:

41 Likes
2

Love how the pipe can go both ways. Don’t think I’ve seen that before. :grin:

3 Likes
3

Take a look at some functional programming languages such as Haskell. This operation is typical for these languages.

4

To go both ways? I’ve seen the pipe operator before, just not going to the left, I guess. Maybe I just never looked, that’s also a real possibility. :sweat_smile:

5

Yeah. They can be called sequential compose operators, for example. Haskell specifically uses operators such as <<, >>, <<=, >>= etc. to achieve these piping operations.

1 Like
6

These pipe operators don’t actually do composition; <| is the equivalent of Haskell’s $, and |> the equivalent of Haskell’s slightly-less-common &.

The names of both of these operators should be familiar to F# programmers.

Edited to add: if you have good or bad experiences with these operators, please comment on the RFC! We need community feedback to work toward eventually stabilizing this feature, and then being able to use it in Nixpkgs.

11 Likes
7

Aha. My bad. Thank you for the clarification on which operation the operators actually perform.

8

Is there a policy when 2.24 will get the default Nix version in Nixpkgs? I am still using 2.18.5 on current unstable. I’ve heard there are regressions which make an upgrade impossible?

2 Likes
9

Normally after all known major regressions are solved. There is a PR bumping the version: nix: 2.18 -> 2.24 by roberth · Pull Request #335342 · NixOS/nixpkgs · GitHub. And you can see all blockers.

3 Likes
10

I just noticed from Release v0.26.3 by grahamc · Pull Request #1200 · DeterminateSystems/nix-installer · GitHub that Nix 2.24.8 was released. (Update: The link should have been Release v0.26.3 · DeterminateSystems/nix-installer · GitHub, which is a bit clearer)

Is there any more official way to find out about these releases? Is there a changelog? For example, when a security breached was fixed in 2.24.7 (or .6?), I had to rely on word of mouth to find out; I couldn’t find a changelog that said that it was fixed.

Update The changelog I could find is Release 2.24 (2024-07-31) - Nix Reference Manual, but it doesn’t mention changes in patch releases.

4 Likes
11

Yes, that’s not great. I take note to get more diligent with our processes. We really should put more effort into writing and editing release notes and announcements, and automating distribution of that information.

Help with that is greatly appreciated – if you’re interested in writing things down, subscribe to updates on the Nix repository, review open PRs to make sure they have good release notes, build tooling to automate chores, or join the team meetings which is the easiest way to understand what’s going on and how you can support development.

2 Likes