1. 18
  1.  

  2. 3

    This is essentially the same idea behing Nixos and also my own package manager / package build tool - https://github.com/andrewchambers/hermes

    1. 2

      Yeah I think what it comes down to is who actually builds a quality package ecosystem. The build / package software is one thing, but building a high quality repository is 1000x more work.

      As mentioned in chat, Nix does have a lot of packages, but they don’t have a great story for Python packages on top of native packages (or R, node.js, OCaml, etc.). The Nix build for Oil is sort of in limbo because of that issue.

      All those language package managers have no connection to the native package manager. They just treat it as a Docker-like blob (which is why people use Docker – it doesn’t require them to fix other people’s crazy build systems. They can just paper over the problem).


      I followed the last link in the article and found this post (which I will submit as a top level post)

      http://blog.williammanley.net/2020/05/25/unlock-software-freedom-one-by-using-better-tools.html

      The challenge is the sheer amount of software to be packaged is tremendous. Having a complete view of the build graph requires converting every package to the same build system.

      The reason Docker is popular because it doesn’t require solving that. The convention in Google’s Bazel (mentioned in the article) is to throw out all the autoconf and GNU make and rewrite the build system from scratch. That works pretty well for C++ and code you wrote yourself, but not well for code that already has a quirky build system.

      Nix doesn’t require you to throw out everything, but I think it’s a little further toward that end of the spectrum.


      As usual the problem with changing a software ecosystem is a strong network effect… People are using Debian and Red Hat images, so developers write their build systems to work on those kinds of machines. They don’t work as well on Nix images – there’s more work you have to do to make it work. So whenever new people want to use those packages, they use whatever system the build system works on, which is something that looks like Debian or Red Hat.

      1. 2

        Oh I don’t think it’s really the same, because they mention they’re using apt2ostree:

        https://github.com/stb-tester/apt2ostree

        So it’s not totally a source build, and I think that’s actually a good way to start. It’s a middle ground to get something working.

        In other words, the ideal solution for build and deployment to me is something that’s as easy to use as Docker but as “correct” as Nix or presumably Hermes. But those two properties are in conflict. There are a bunch of tradeoffs to be made, and what I see in this post is pretty encouraging (I still need to try it)

        Other good links from the post:

        When I made an attempt at this problem 5+ years ago I looked at such tools, e.g. I remember Project Atomic. But it’s great to see the state of the art advancing. Ninja + OSTree seems like a promising combo. I think OSTree does the differential compression part, which is not easy.

        1. 2

          One thing to realize is the Nixos model would work with ‘regular’ packages if you just set DESTDIR to $out instead of PREFIX. You just need an extra mounting step with fuse to actually use the package.

          So yes, it is the same model. The way Nixos works is totally compatible with this approach without changing anything in the design of the package manager tool. This is something I hope to experiment with in hermes as an alternative package tree.

      2. 1

        Very cool! OSTree and Ninja sounds like a good combo.

        I have a use case for continuous builds and building distros with Oil here:

        https://github.com/oilshell/oil/issues/756

        If anyone is interested in chatting about it let me know :) I’ve only played a little with NInja and OSTree a very long time ago