Nix is a functional programming language and a package manager that allows you to arrange the packages of many ecosystems, not just Javascript or Java, as Node and Maven do. It is like writing a declarative package file.json or pom.xml but quicker. In addition to dependency management, we get a flexible, reproducible development environment for free.
Nix has a lot of features and can be used to solve some common problems:
1. Replacing language version managers such as nvm, rvm, and virtualenv.
2. Separate development dependencies from user dependencies.
3. Create a simple CI process.
The goal of the Nix language is not to become a general-purpose programming language like Haskell or Scala but to make it easier to write a declarative definition of a package (called derivative in the Nix community) for any programming language and any other application or tool.
The definition of a Nix package is very similar to Json. To build the myProject package, we need a Bash shell environment, a Node Javascript interpreter, and a C library. We also need to run the build script. We can mix many ecosystems as dependencies for our package.
At the same time, the enormous power of a Nix functional programming language is used. This syntax may seem strange, but it is similar to other programming languages like Haskell. Do not worry if you have not programmed in such a language before.
Nix attributes
The most important concept in Nix is called “attribute set,” but you can think of it as a Javascript object with key-value pairs.
A Nix package definition is a set of attributes with consistent attribute names. These attributes define all dependencies and the necessary steps (builds) to compile this package and use it as a library or application.
Version Manager
Many popular programming languages have a version manager that installs multiple language versions side by side. After using rvm for Ruby version control and nvm for Node.js, people ran into some issues with them and started looking for alternatives. We have found that the Nix shell functionality discussed earlier provides a more isolated and maintainable solution than language version managers
Nix provides tools for specifying an archived version of the desired dependency to be extracted and compiled from the source. Even if Nix doesn’t have the latest version yet, you can still get the source code and build it with Nix.
Two main advantages
Let’s look at two advantages closer.
Reproducibility
This is the most obvious advantage since it is the main motivation of Nix. Two people assembling the same package will always get the same result if you are careful enough with pinning versions of the input data. And even if some of the input data is different, it will be clear because the path to the storage will change.
Another advantage we get from Nix is binary caching. Since the path to the repository is known before the package is built, we are sure that the same path to the repository will contain the same output, we can replace this path to the repository from another location if there is this path in that location and we trust whoever creates it.
Binary caching
NixOS
These advantages are good, but Nix can be extended. We have only described how to perform reproducible builds and have not said anything about runtime consistency.
How can we be sure that the application will have the same configuration files that the Linux kernel version has every time we deploy it on the server?
NixOS is a Linux distribution that uses Nix as a package and configuration manager. Each configuration file is described as a derivative, and your system is a derivative that depends on all the applications and configuration files you have specified. This way, you get all the benefits of Nix applied to our runtime environment. If two people install an OS system with the same storage path, they will always get the same system on their computers.
