Nixery – Docker images on the fly with Nix

Post by stabbles » Tue, Apr 19, 2022, 4:15 PM UTC

frafra wrote: post #49

stabbles wrote: post #34

I like how they optimize for layer reuse, but at the same time, nix doesn't really fit docker layer caching because it's better. With a unique prefix per package, you don't need stacking of layers. You can just download a bunch of packages in parallel, extract them in parallel, and finally "merge" the prefixes to get those combined bin/ and lib/ dirs.

> You can just download a bunch of packages in parallel, extract them in parallel, and finally "merge" the prefixes to get those combined bin/ and lib/ dirs. docker pull achieves the same result: layers are fetched in parallel, and they are extracted using pgiz (parallel gzip). It just uses a pre-defined order, which does not harm performances, but it is not useful either in case nixery is used.

Post by JamesSwift » Tue, Apr 19, 2022, 4:18 PM UTC

codingkoi wrote: post #62

JamesSwift wrote: post #58

Earlier quoted context omitted.

If you just want to take a precompiled binary and install it, you just have to write a derivation wrapper around the binary which will declare the expected hash and take care of e.g. unzipping and moving to $out/bin. Here is a more involved example of downloading a release and then extracting the binary from a .pkg file: https://gist.github.com/J-Swift/364a8b158bf0b603f6e784e454ca... Here is a more simplified example…

Once I discovered `lib.fakeSha256`, I just put that in the derivation, try to build it and then use the error message to find the correct hash to put into it. Probably not the fastest way to do it, but it's easier for me to remember.

Post by lijogdfljk » Tue, Apr 19, 2022, 4:24 PM UTC

colordrops wrote: post #48

nickysielicki wrote: post #12

I don’t know if it’s just because I hopped on the bandwagon in the past few months, but it really is starting to feel like Nix is gaining momentum. You can use it on Mac, WSL, Ubuntu multiuser, Docker, in an nspawn container, or through NixOS on a drive. You can build a livecd iso or a Raspberry Pi image from the same flake that you use for everything else. I work in embedded with Yocto every day, and I can’t help bu…

I was afraid of Nix before I adopted it based on what I've read. Now that I've taken the leap, there is no going back. Other operating systems are crude dinosaurs in comparison. Once you get past the learning curve and the initial setup (which can be steep), your system will be far more stable and easy to maintain than anything out there. Declarative OS builds are the future, whether it's Nix or something else.

Post by dboreham » Tue, Apr 19, 2022, 4:39 PM UTC

chriswarbo wrote: post #26

exdsq wrote: post #4

Oh great! More indirection. Now when I want to deploy my web app I can check my private nixery.dev deployment is properly configured in Nix to build my Docker images so I can deploy my containers to the cloud so someone can access me Rest API. And the cost of guaranteeing builds will probably work? Running your own nixery service, learning Nix, and learning Docker. I would love someone to do a cost-benefit analysis o…

> I would love someone to do a cost-benefit analysis of these sorts of tools against the time of using (and sometimes debugging) Make and/or Bash. Nix does essentially the same job as Make. The differences are: - Make embeds a shell code interpreter, whilst Nix just execs a binary; given its path, a list of args and a set of env vars. (Note that almost all Nix definitions use bash as their binary!) - Make does meta-p…

Post by abathur » Tue, Apr 19, 2022, 4:53 PM UTC

microtonal wrote: post #57

abathur wrote: post #44

Earlier quoted context omitted.

> and the initial installation experience on Mac has been all over the place quality-wise in recent years. In minor defense of this, Apple making the root read-only threw a pretty big wrench in things. There are a lot of little reasons (some understandable and some exasperating) it took so long to adjust, but all of them were exacerbated by the amount of new logistical complexity required (and the amount of experimen…

Most of the issues come from the lack of enthusiasm for moving the Nix store somewhere else than /nix . Even with read-only root, macOS has some designated locations where you can write. E.g. Homebrew uses /opt/homebrew , which is fine because /opt is writable. I understand the reasoning of avoiding this on Intel Macs, since there there are years of cached derivations which would become useless without hacks. However…