The Power of Nix: Developing, Building, and Deploying a Phoenix App
The inordinate usefulness of Nix really sinks in when you realize that it allows you to define a single piece of unified infrastructure for handling all the different parts of the software lifecycle. Furthermore, this infrastructure doesn’t even need to be project-specific. For a given class of projects, the “holy grail” Nix flake template defines all the following: All the dependencies, pinned in the flake.lock and updatable with nix flake update. A dev environment accessible with nix develop. A package derivation that encapsulates the build process in a nix build command. A module that exposes the app as a configurable system-level service that can be leveraged in integration checks with nix flake check. With these things in place, activities that traditionally create overhead for developers (environment and deployment) are abstracted and standardized. And even though other tools solve similar problems, none of them achieve the universality of the Nix model. That’s because the most natural and complete description of software packaging is as pure functions over store paths. But in this post I’m focusing on convenience. The correctness of Nix, and the fact that correctness leads to convenience, are topics for a different post. ...