Threads for matthewcroughan

  1. 2

    but Dockerfile is much more simple and easy to use.

    1. 20

      simpler to start, harder to get the details right - especially as your matrix of (supported platforms to run and test on * variants of your software to package * external depdencies to handle) grows.

      The learning curve with nix is much steeper - far too steep atm IMO, but its being worked on; flakes and the new nix cli are a step forward. - but nix covers much more ground than dockerfiles as well.

      Come for the dockerfile replacement, stay for the generic build system, whole-system configurations, home-manager and more.

      1. 12

        As someone who has made both Dockerfiles and a flake.nix for a project, as well as currently use both Nix and Docker/OCI tooling almost daily, I just cannot agree with most of your assertions.

        Even amongst nix flake enthusiasts there is conflicting info on how to do a nix flake “properly”. The examples in the video showing the problems with Dockerfiles are convoluted. How often do packages go missing from debian or ubuntu? If you’re using “ubuntu:latest” and don’t mean to, then you’re doing something wrong (and also unusual) - normally you would pin to a version (i.e. “ubuntu:20.04”) or even specify the exact hash of the image you want to use.

        My feeling is that Nix flakes and Dockerfiles prioritize different strengths and to say one is the replacement for the other is kind of like saying “shoes are better than sandals! you won’t stub your toes and you wont get wet.” okay… well what if that’s not what I prioritize…

        1. 6

          I’ve worked with both as well, and I can’t disagree ;)

          Even amongst nix flake enthusiasts there is conflicting info on how to do a nix flake “properly”.

          Yes, this is unfortunate. But to be fair, flakes are still “experimental” and might not be “there” yet for any possible use case, but they do already support a wide variety of use cases. Especially when combined with flake-aware tools such colmena or support libraries such as flake-utils(-plus).

          My feeling is that Nix flakes and Dockerfiles prioritize different strengths

          That’s a good point, that I’ve tried to make as well. Dockerfiles are definitely more “portable” between your co-workers or community members.

          But nix(os) offers a rich eco system, where you can choose tools and parts to build beautiful OCI images (or whole vms, from the same expression!) and which don’t break because some dependency in your ubuntu base image does not match with your third-party repo or npm dependency. We’ve all been there, I guess :D

          1. 1

            Sidetrack to say that I’ve done the pin to ubuntu sha hash and that ends up not working after a while when a package is renamed or does go away because of version bump in the package name itself or similar. I don’t remember the exact details but it sucked being bitten by pinning of the image but that doesn’t matter when the apt repository changes between image build runs (on the order of months).

        2. 6

          Looks simpler, but has way more pitfalls

          1. 5

            At a great cost. That cost is reproducibility. And I value that more than anything. Though different people value different things.

            1. 5

              Reproducibility is a term which means different things to different people. There are plenty of occasions when nix expressions are pulling down binary blobs. So definitely not reproducible from source in all cases. I like Nix, and use it daily, it’s just more pain than benefit in most places where I use Dockerfiles.

              1. 3

                If you had watched the talk, I explain that Nix is only making the claim that the inputs will be the same every time. That’s all it does, and all it can do. Build determinism is assisted by the sandbox. Read the section of the thesis called “enforcing purity” to learn more.