Nix - Next Generation Package Manager

    Hello everyone,

    Today we’ll talk about Nix , a purely functional package manager.



    Why create another bike, this time with square wheels purely functional?
    Existing solutions:
    • can’t cope with updating packages (updating can delete old packages, because of which you will either have to delete all programs dependent on these packages, or put up with inconsistent state of the system)
    • do not take into account all the dependencies of each individual package (and cannot do this)
    • they don’t know and cannot know the exact combination of kernel versions, libraries and packages available on the computer
    • focused on centralized repositories, each of which will have a single package naming policy - as a result, the packages of these repositories are often incompatible, even if the same underlying technology is used (RPM, DEB)


    As a result, a lot of hard work falls on volunteers who vigil day and night in the service of the fatherland. :)

    How to solve this problem? Very simple, said the guys from the University of Utrecht: handle packages the same way as with the values ​​of evaluating expressions in purely functional languages! How-how, the reader will ask again?

    Like that:
    • a package is the result of evaluating a pure function whose arguments are all package dependencies (other packages, that is)
    • the package, once installed in the system, does not change (no side effects)


    The two sentences above only mean that Nix never makes changes to files on disk, but only creates new files.

    “How so ?! I only have a 2 GB drive! ”- probably the reader was visited by something like this. :) The fact is that some packages can be safely removed if other packages do not depend on them. This is very similar to garbage collection in modern programming languages.

    We list the most notable advantages of Nix over other package managers:
    • it is quite possible to contain several versions of the same package at the same time (for example, it can come in handy if two certain applications require two versions of the same library) We
      note right away that update or delete operations cannot damage other applications because these operations never Do not overwrite or delete files used by other packages.
    • all dependencies of a single package are monitored - a package that has earned on the developer's machine will also work on the user's machine
    • atomicity of update operations and the ability to roll back any update (even if you pull the plug out of the socket during the update, the system will not suffer from this - but this, of course, should not be done for obvious reasons)
    • transparent support for packages containing source code or compiled binaries ( Nix may automatically skip the compilation phase if the package is already available in compiled form)
    • binary patches (in addition to downloading the available binaries automatically, Nix can download the difference between the two binaries)


    On this optimistic note, we conclude our reviewer.

    update: formatting
    update: moved to the collective blog

    Also popular now: