NixCon 2020: Online Edition

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.