1. 14
  1.  

  2. 9

    Using nix to distribute RhodeCode was the best decision we made for how we distribute our software. It removed all problems we had with python packaging just using virtualenv. I think the key benefit is that our installation survives system upgrades while we had almost 40% failure rate in this case with previous virtualenv based installer.

    1. 5

      Would you be interested in doing a whitepaper?

      1. 3

        Do you instruct end users to use Nix, or do you have some custom installer that somehow hides Nix from the users?

        1. 5

          We abstract it. End users just run a single binary that creates full nix env, and unpacks all dependencies into a custom nix store.

          Nice things are that on upgrades we still have the full tree of old dependencies, so, for example, rollback to the previous release is just swapping a symlink.

          1. 1

            This reminds me of the guix pack command: https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/

            Would something like that (e.g. ported to Nix rather than Guix) make life easier? I imagine that including Nix itself in the artefacts you distribute would make things quite bloated. (I’ve never used Guix, but I’m a big Nix fan :) )

      2. 1

        I really love nix, but was recently wondering if there is a way to simplify the design a lot.

        I was thinking this might be accomplished by making a hybrid of nix and djb redo. A system where .do files hash to the output directory of where they compile to. The key idea (I think, though haven’t fully fleshed it out) is that redo allows efficient dep checking AND the output dir of your deps doesn’t need to be known until after the build.

        My main motivation would be to get most of the benefits of nix in a simpler to understand system.

        1. 1

          Nix does more than build software - it manages configurations. For that, you really do want a Turing-complete language, despite the complexity.

          At least to me, that’s the primary benefit. Nix doesn’t really do anything novel as a build tool, it just wraps other build tools to make them hermetic.

          I agree that hermetic builds are worth studying fully and providing in many different ways. :) I think any time you’re building a package that has dependencies, you need some form of configuration management to make it work. So I don’t think the specific simplification you have in mind is feasible. But it’s well worth thinking about why.

          1. 4

            I kind of think of the Nix language as being like JSON with lambdas. So Nixpkgs is mostly a huge nested record of data, but lambda abstractions make it reasonably possible to build up without enormous amounts of duplication in the source tree.

            It’s not clear why Nix is perceived as hard to understand, although I also had that perception. The language is really (truly) simple. OK, one thing that’s tricky is how most files just denote functions, and it can be hard to understand where the arguments are coming from and where the call sites are.

            Some kind of visual explorer of the Nixpkgs tree would be really sweet.

            1. 5

              I don’t think the language is too bad, it is that the system is a set of conventions that are totally under documented and there is little information available about quality control and security measures in the core tree. I also question some of the decisions and defaults. For a tool which is designed to be reproducible, lots of the defaults are not, and you need to dig deep into the system to learn how to do things that should be the default.

            2. 2

              Yeah, the reason that nix works so well is it is the high level build tool, config tool and also deployment tool with nixops. That level of integration is hard to beat and lets you do some powerful things most people don’t realise are possible. (One of my favorite things being that build artifacts are just a cache, and source level packages are first class.)

              I would love a tool like nix(ops) for BSD systems with some of the BSD cultural influence.

              1. 2

                For that, you really do want a Turing-complete language, despite the complexity.

                shell is turing complete. You would need to take care to hash the env and the script arguments. But I agree, things get hairy when it comes to composing a very large system.

                1. 1

                  Agreed - I guess the alternative I was imagining was a completely static configuration, not a shell script. :) I’m not sure if that maps onto what you were proposing at all.