Hacker News Reader

Comment by CapsAdmin | Hacker News Reader

I feel a little lost on nixos. Been using it for a while now on my main personal desktop and it's fine, but whenever I want to do something like running a python project (ml based ones for example), or compile software from source, I'm lost because I don't know what I'm doing. Most projects target Ubuntu, so I feel you need to know a lot about how nix really works to get them compiling, which is often not what I'm in the mood for tinkering with when I just want to test something.

So in the end I end up using distrobox with Ubuntu which works surprisingly well, but feels very hacky as I'm supposed to try and use nix. The way I rationalize this is that I'll get rid of distrobox slowly over time as I learn how it works.

View on HN

I've used Nix for 5 years now and use it heavily in production, and in my opinion, just do what works for you. If you try and use Nix 100% "correctly" then you'll end up like the countless other people who tried Nix and failed.

Especially for toying around in dev environments, be pragmatic and take advantage of its amazing strengths, but if distrobox lets you enjoy using NixOS and speed up your workflow, so be it.

Heck I'm spinning up some services in production just now and I'm reaching for Docker Compose as that's how the vendor officially supports deploying their software. Turns out NixOS can still bring some benefits to a Docker Compose workflow, deploying it via a systemd service, config managed in Nix, it's not as nice as building the service entirely in a Nix derivation and deploying it natively, but it's still better than without NixOS.

How are you managing docker compose with nix? Individual docker containers are easy to manage with `oci-containers`, but there's no obvious way for compose. Unless of course you're just writing the systemd configs in nix.

Yeah I normally use oci-containers but for this workload the only supported method of installation is a `docker-compose.yaml` file.

I've just written a systemd service that does `docker compose pull` and `docker compose up -d --remove-orphans` with the compose file being written to the Nix store, works well.

Or you could... You know... Not use Nix?

So give up all my baseline hardened VM configurations and go back to patchy Ansible scripts that leave the OS in a different state every time? No thanks

Are you keeping any of your configurations in a public place to use as a starting point?

You are supposed to use shell.nix, list the packages that the project lists in README and then you can use the normal README instructions. Unless you really care about doing it "pure nix way", (e.g. writing mkDerivation, which is waste of time in a dev env)

Reply on news.ycombinator.com