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.