1. 38
  1.  

  2. 7

    I have been trying to package something with Nix for a couple of days now and the experience is just horrible. The documentation gets worse and more esoteric the deeper you go - thanks for this article, will allow me to un-bodge a bodged part of CI (just to bodge it differently, but still).

    1. 11

      Yeah, Nix the language is fine overall. What’s most difficult are all the libraries that ship with nixpkgs. It’s impossible to use them without reading the code. And there are small variations that prevent knowledge from being transferable.

      Hopefully, the article helped bring back a bit more Dockerfile-like experience.

      1. 13

        Even reading the code is laborious due to dynamic typing and utter lack of documentation. If some package function takes an argument and passes it to some other function, and you want to know what type that function is, you need to find every call-site for that function or else go down the call stack and find every usage for that parameter. It’s an absolute grind.

        1. 3

          +1 to the nixpkgs libraries being tricky to follow/understand.

          This was a major motivator for my in-progress switch to Guix (which has its own issues).

          I find the library aspect of Guix much easier to follow, since they’re written wrt records with decent levels of abstractions (see the operating-system record, for example).

        2. 4

          While the whole nixpkgs is complex and lacks good docs, I’ve found it not that deep in the end. There’s a few language-specific abstractions to learn, nix language itself, but then… in the end it’s functions generating shell scripts. The serious problems remain where they are with any packaging - getting a reliable, reproducible environment. So for example dealing with Darwin sdk quickly becomes the biggest problem rather than nix.

          This is not a disagreement with your experience, i also think it sucks. Just a note that “more esoteric the deeper you go” flattens out surprisingly quickly. I think I “got” nix quicker than deb/dh.

          1. 4

            Ah, then can you help me find out how to change the kernel in NixOS to L4Linux? I hit a cognitive wall around cross-compilation, especially trying to introduce a new architecture (L4Linux seemed to require this, or maybe it looked like a reasonable way forward when I tried doing this).

            1. 1

              I think that one would deserve a blog post rather than a lobsters comment :-)

              1. 1

                I’m fine whichever way you prefer!

            2. 1

              in the end it’s functions generating shell scripts

              This idea alone scares me

              1. 2

                Most of the packaging is running configure, make, yarn, cargo, install and others. It all reduces to firing up a few processes at some point. Why is it scary?

            3. 3

              The best documentation is the implementation, for better or for worse

              1. 2

                Nix documentation is bad

                Just how long should it stay like this? This something I’ve been reading for, what, 2 years…

                1. 9

                  The documentation is awful and with the push for Flakes over regular derivations the situation is getting worse. It won’t be better for a while, although what exists is usable. But trying to do most non-trivial things requires finding someone who’s done something similar and using it as an example. I am trying to understand more of the ecosystem so I can start an alternative Nix/NixOS wiki. The current wiki is full of outdated and poorly explained disparate pieces of information and should really be more like ArchWiki.

                  1. 1

                    I don’t know how management of these projects work, but can’t they like, just assign 150k for two devs for two years to fix the documentation once and for all?

                    1. 10

                      You got 150k laying around and two people who know enough about Nix but don’t care to hack on it directly?

                      1. 4

                        You can certainly motivate people using pooled money. Nix macos is being supported through https://opencollective.com/nix-macos so maybe the documentation could be done the same way.

                        1. 2

                          Because it’s a technical problem. Documentation is a tough nut to crack. Technical people often don’t even know how to tackle it.

                  2. 4

                    Until a hero comes along.

                    The NixOS project is largely driven by volunteers. Volunteers work on the things they are interested in. And you get to benefit from it for free. That’s the deal.

                    It’s not some corporation where you allocate Human Resource on the docs. You need to actually get people interested in solving the problem, and it’s hard. Most people in open source are technical people, and they like to solve technical problems.

                2. 1

                  Thank you! This is awesome and will make it (one hopes) easier to introduce nix in an enterprise setting / work with nodejs projects.