Nix modules: Improving Nix's discoverability and usability
Nix modules: Improving Nix's discoverability and usability - Eelco Dolstra
2020-10-16 https://cfp.nixcon.org/nixcon2020/tal...
Nix's configuration language is quite powerful but suffers from a
lack of discoverability, usability, and consistency. In this talk, I'll
describe an experimental Nix module system that provides a consistent,
discoverable mechanism to write configurations such as packages and
NixOS systems, and show how this enables a better user experience for
both new and advanced users.
----
Nix's configuration language is quite powerful but suffers from a
lack of discoverability, usability, and consistency. To name just a few
examples:
There is no easy way to find out from the command line or from the
REPL what arguments are supported by functions like
stdenv.mkDerivation or buildPythonPackage.
Mechanisms like the .override attribute provide an almost unlimited
ability to customize packages, but the only way to figure out what
you can override is to read the source of the Nix package, and
writing overrides is often black magic.
NixOS has a nice self-documenting module system, but Nix packages
are written in a completely different functional style.
The Nix CLI doesn't know anything about package functions, .override
and .overrideDerivation, the NixOS module system, the Nixpkgs
config attribute set, Nixpkgs overlays, or any other customization
mechanisms that have emerged over the years.
The syntax and semantics of Nix expressions are often an obstacle to
new users and have a steep learning curve.
In this talk, I'll show an experimental Nix module system, similar to
the NixOS module system, to replace the "functional" package style
using in Nixpkgs. This means that functions like mkDerivation or
buildPythonPackage as well as packages become modules that can build
on each other. For instance, the "GNU Hello" package is a module that
inherits from the unixPackage module, which in turn inherits from other
modules like derivation. Package customization is done in the same
way: by inheriting a module.
These modules, just like in NixOS, have types and documentation. As a
result, everything becomes discoverable and modifiable from the
command line. For instance, there is a command nix list-options that
shows everything that can be customized in a package. It also provides
a standard for documentation: the command nix doc generates HTML
documentation for the modules in a flake.
Slides: https://cfp.nixcon.org/media/nixcon-o...
