Tweag + Nix dev update #9

Another month, another dev update from the Tweag Nix team:

Content-addressed Nix

We’re closer than ever to having this properly usable.
In particular, two big PRs by @thufschmitt got merged:

  • #4592 brings a proper transparent substitution to content-addressed derivations,
  • #4618 allows signing them like we can already do for input-addressed ones.

Another one (#4624) also temporarily introduces a new nix realisation command to make it easier to work with these during the development phase.

Nix UX

  • @edolstra made the behavior of --override-input more intuitive by not writing the lockfile (77f5d1)
  • @edolstra merged the very similar nix flake inputs and nix flake info into a single nix flake metadata command (66fa1c)


@adam is heavily working towards bringing Trustix to life for real with its first public deployment − in particular ensuring that it can be properly packaged and deployed with Nix.

In addition,

  • The frontend saw a nice amount of work, getting cleaned and prettyfied in a lot of places;
  • The development experience got a nice overhaul too, making it easier to contribute

Summer of Nix

Several of us had the chance of participating to the organisation of the summer of Nix, brainstorming with other community members before the official announcement, and now interviewing candidates.

In case you missed the announcement and are interested, go check it out at


In addition to numerous bugs fixes,

  • Yann did a really huge amount of work on the Nickel stdlib (and it’s still improving), so that it comes with all the batteries you might need. This is tracked in #254.
  • Some early internal testing also led to various syntactical and usability changes (#327, #317, #322)
  • Parts of the typechecker got a nice clean-up fixing some midly annoying quirks (#315, #314)
  • Yann opened an RFC issue on the design of record overriding, taking lessons from the various Nix extension mechanisms (NixOS modules, overlays, POP, etc…) and other similar systems in the wild (cue, jsonnet, etc…).



@infinisil I’d be interested to include a cheap way of showing a list of unmaintained packages into the new nixpkgs devshell, so that people can have an easy time reviewing periodically to check if they want to step in.

Maybe you can keep that specific use case in the back of your mind, while proceeding.

For example, if an issue would be opened for each unmaintained package with a specific backlog label, gh issue list --label='0.kind: unmaintained' would already render quite compelling UX for that matter.