Live data from Hacker News

Nixery – Docker images on the fly with Nix

nixery.dev

71–80 of 90 posts

Re: Nixery – Docker images on the fly with Nix

#71
post #55

Earlier quoted context omitted.

Okay, sorry to hijack, but I keep trying it, and keep getting stuck. Most recently, how do I install a Rust binary from Github? They have a releases page, or I can just do a cargo build. Either way, I would just drop the resulting binary in /usr/bin and it's done. With Nix... I'm totally stumped. Do I have to package it myself somehow?

Yes, you will have to package it if it's not already in nixpkgs. The good news is once you learn how, it's basically trivial with crate2nix[0], which can autogenerate nix derivations from rust crates [0] https://github.com/kolloch/crate2nix

You can also use naersk¹ if you want to avoid a two-step process. It's especially convenient when using nix flakes.

¹https://github.com/nix-community/naersk

Re: Nixery – Docker images on the fly with Nix

#72
post #68

Earlier quoted context omitted.

I actually hate Nix.. and i agree, i'm never going back. I use it on my desktop (Linux), my Macbooks, and i want it on my Windows machine (not that it's going to happen hah). The thing that Nix, for me, currently fails at is introspection. Every function is a black box and i have no clue what's in it. I have to go dig up files on github to see what it even accepts. It's as if everything is obtuse. A "simple" LSP/Type…

Guess I know what I’m learning this weekend. Anyone have tutorials they want to share?

I'm about a year into Nix and consider myself a moderate in some areas but something of an expert (by necessity) in others. I think the ideal pattern is to attack it bottom-up and top-down at the same time.

Bottom up, you want to learn the fundamentals of how the Nix language works, and how the basic primitives it offers can be used to build up package definitions, a package manager, and ultimately an entire OS. For this, the Nix Pills are invaluable: https://nixos.org/guides/nix-pills/

Top down, you need goals for some specific things you want to accomplish in the system. For me, this was automated packaging for hundreds of source repos internal to my company, but that's a bit of a crazy case— for a normal person, I'd expect this could be something like "I want to run a webserver with some static assets" or "I want to define and launch a container declaratively", or maybe "I want a reproducible environment to do Python development in, where the reproducibility isn't just tagged versions in a requirements/pyproject file, but also includes the full underlay of everything I'm depending on from the base system.

Whatever the goal is here, you're inevitably going to find your way to override-related tasks, like "okay, I want to upgrade this package" or "I want to add patches to this package" or "I want to change the settings on one of my dependencies", and that's where the extraordinary power of Nix really starts to sink in, when you realise how much can be accomplished with so little, and you try to imagine what accomplishing that under a conventional apt- or dnf-type system would look like.

Re: Nixery – Docker images on the fly with Nix

#73
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…

It's not that easy to change the default store dir.

https://cache.nixos.org/nix-cache-info has it hard-coded to /nix/store. If you want another one you'll need a whole new cache. But Hydra only works with one cache, so now you're deploying a second Hydra build farm.

One of the cool features of Nix is that you can evaluate some nix code on macOS even if the target build host is Linux. And then ship the .drv over to the build host. But that only works if both hosts share the same store dir.

So now you're looking at moving the whole community to use /opt/nix. And thinking of how to upgrade the existing users to it. And fix all of the tooling we built that assumes /nix/store as the store dir.

So far nobody had the courage to tackle this huge task.

Re: Nixery – Docker images on the fly with Nix

#74
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…

Nix makes a lot of sense if you really understand build system. But makes less sense if you understand operations, or management. Real world engineering is about trade-offs, and Nix has no wiggle room for compromise. It’s optimizes on one dimension: Reproducible builds. But an organisation won’t succeed when it places the needs of build system engineers on a pedestal.

You can always set `__noChroot = true;` on your derivations and forgo the sandbox. Then it's not more difficult than a Dockerfile really.

Re: Nixery – Docker images on the fly with Nix

#75
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…

Yup, this. I think a big part of this is that Eelco is really only interested in NixOS. Nix is a large community and there are plenty of people that do care about other platforms, so these things do tend to get sorted out. Still, the core devs will choose to avoid short-term, medium-painful transitions for NixOS even at the expense of killing all the other platforms.

Re: Nixery – Docker images on the fly with Nix

#76
post #29

In the same spirit but in the form of a readily-usable command (rather than a service), 'guix pack' can produce application bundles in a reproducible fashion, in the Docker format as well as in other formats: https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix... Hopefully the smart layering strategy that Nixery uses will eventually make it into 'guix pack'!

`nix bundle` is similar: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...

Interestingly, it already supports Docker images:

    # nix bundle --bundler github:NixOS/bundlers#toDockerImage nixpkgs#hello

Re: Nixery – Docker images on the fly with Nix

#77
post #54

Earlier quoted context omitted.

Yeah I was in a company using Nix for around 18 months where some of the DevOps team were contributors so everything was Nix’d. CI, dev environments, deployments, cluster management. Want to add a library to your Python app? Don’t use pip or poetry, update Nix. But because DRY this nix isn’t even in your project, it’s in another repo somewhere. Want to update Haskell? Well you can’t use Cabal or Stack, you need to us…

> when the total Nix lines of code > 10k for a project then have fun! I have the suspicion that you’re talking about auto-generated Nix code. For comparison, lock files for language-specific package managers can easily exceed 10k lines. But I have yet to see any hand-written Nix build description for a single software project reach nearly as much LOC.

I just checked and without giving too much info I’ll round, but there’s 20 repos with 10K commits of pure Nix repos, 3k issues across them, and 30k references to the word nix lol. Random check and none of the files are generated in these repos - it’s all reasoned code judging from commits. These are then used across all projects which includes additional nix stuff.

Going for the entire org and these numbers increase drastically but could include auto generated nix code.

Re: Nixery – Docker images on the fly with Nix

#78
post #28

Earlier quoted context omitted.

How can one use Nix to manage project-specific dependencies that typically store Dotfiles in annoying locations like the home folder? I am aware of home-manager but am not sure how (or if) it would work for per-project dot file management.

Can you name a tool which does not allow per project local configuration files? One option to do it per project with hm would be to add new options which set certain configuration options.

Considering any command-line tool that requires a dotfile to be in some ~/

Re: Nixery – Docker images on the fly with Nix

#79
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

Spot on! But HN is so biased towards new or flashy stuff...

Re: Nixery – Docker images on the fly with Nix

#80
post #68

Earlier quoted context omitted.

I actually hate Nix.. and i agree, i'm never going back. I use it on my desktop (Linux), my Macbooks, and i want it on my Windows machine (not that it's going to happen hah). The thing that Nix, for me, currently fails at is introspection. Every function is a black box and i have no clue what's in it. I have to go dig up files on github to see what it even accepts. It's as if everything is obtuse. A "simple" LSP/Type…

Guess I know what I’m learning this weekend. Anyone have tutorials they want to share?

I would read a bit and look at the nix-pills [1] even though I could never understand them when I was learning. Then, what I always recommend is this playlist by Burke Libbey on youtube [2]. There are a couple fundamental things that you can internalize which will make everything much more approachable:

1. Nix the language is basically a JSON object. Almost everything is about generating and composing subtrees to build a _really_ big JSON object.

2. `` means from channel `foo`. This is less relevant now with flakes but that was always extremely confusing syntax to me and when I "got it" it made things way easier.

[1] - https://nixos.org/guides/nix-pills/

[2] - https://www.youtube.com/watch?v=NYyImy-lqaA&list=PLRGI9KQ3_H...

Post reply on HN