[Dedime]

I've used docker-compose, k8s, and NixOS myself, being from a similar technical background as the author, but I find myself disagreeing with some of the author's opinions on the technologies. They're not wrong of course, but I've had different experiences.

k8s: Installing and using k8s can indeed be a nightmare. In my job, we use Azure, so it's not so bad since launching a cluster is mostly handled by Azure. Setting it up for personal use is less fun. The mountains of YAML you can end up using to deploy even semi-complex services is even less fun. That being said, I've been wanting to use it for a personal project (distributed cluster using cloud VPSs and bare metal at home connected using WireGuard). I just wish it was smaller and faster. Most guides recommend 2Gb of RAM and 2 CPU for the smallest of small deployments.

docker-compose: I actually love docker-compose for my personal stuff. I have an intel NUC hosting homeassistant, pihole, caddy, deluge, jellyfin and a handful of other stuff. Everything lives in a series of folders for each service. Backups (both data and code via git), disaster recovery, and just general reasoning about of it is so easy. The docker-compose files are small and easy to read. I also find docker-compose to be about as immutable as you'd like it - version control your docker-compose directories, pin your image SHAs, and you're in a good place. Or don't, and it will still work pretty well.

NixOS: I've done it. I installed it on my Framework Laptop since it was all the rage at the t ime. I lived with it for about a year, and it was okay - for day-to-day use - AFTER I had spent weeks learning how to use NixOS. I will freely admit it's an awesome technology in some respects. But the documentation just was not there. It was way too hard to learn how to do even basic tasks. I thought nix flakes might be the "aha" moment I was looking for, but I gave up trying to get that to work after a couple of days of troubleshooting. Don't even get me started on trying to package up something from scratch. As a random example, I googled "packaging python for nix" and the top result [1] is just way too complex for something that should be pretty simple. The example includes some abomination of a .nix file with inline bash and python scripts.

I don't really know where I'm going with this. I really do like the idea of NixOS. I just wish it was much, much easier to reason about. Curious to hear what others make of this.

[1](https://nixos.wiki/wiki/Packaging/Python)

[aliasxneo]

Nix has a dedicated following among some of the DevOps members in my company. Luckily, it stays mostly segregated, but I had an interesting conversation with some of them the other day about how awful troubleshooting Nix is. Now, mind you, these are pretty OG Nix contributors, and the response was basically: you have to want it enough.

I had my own falling out with Nix/NixOS over a year ago. I guess I didn't want it enough shrug.

For clarity, I still use home-manager because it's fairly painless, but anything above that is pretty much a no-go for me.

[bkiran]

Troubleshooting Nix is mind-numbing. For some of the benefits, it's the price that is need to be paid

[atrus]

It doesn't need to be paid though, it's just a result of poor design and poor documentation. It's the only OS where I feel like I'm both 20 years in the future and 20 years in the past.

[mikepurvis]

I think it's also an issue with the flexibility paradox. There isn't a good single way to package Python for Nix because before you even start there are several key questions which come up that most other distros can't even begin reasoning about:

- Are we packaging just one Python package for Nix, or a thing and all its dependencies?

- Is the package already on PyPI, and are we packaging the source from there, or is it the source from some upstream?

- Are any of the dependencies coming from source, either their upstreams or forks?

- For dependencies that already exist in the nixpkgs SHA that is supplying the Python interpreter, do we want to use those versions, or package newer versions? Is it the same decision for everything, or does it vary?

- Is there already a Python level dependency locking scheme in place such as poetry/pipenv/uv, or is it a plain setuptools package? Is it acceptable for Nix to become the locking mechanism, or will that mess things up for non-Nix consumers of this?

- Are we looking to supply a development environment here too, or is this purely about deployment?

To be clear, none of this is an excuse— it's horrifying that there can't be a single "Tool X is the singular Python-on-Nix story, follow the one page tutorial and you're all set". But I think the massive amount of choice and flexibility is the crux of why new methods and tools are still being rapidly invented and proposed.

For myself, I would choose poetry2nix as how I'd ship a Python project to Nix hosts, but that immediately implies some answers to a bunch of the above questions, mandates poetry for your top level project, and once you look closer there turn out to be some truly horrifying implementation details [1] that are what make poetry2nix appear as seamless and friendly as it does.

[1]: https://github.com/nix-community/poetry2nix/blob/master/over...

[bandrami]

I can't think of a single external packaging system that actually does Python non-painfully. Then again I can't think of an internal Python packaging system (there are like 5 now) that does Python non-painfully. But since one of the selling points of Nix is "it's like virtualenv but for everything", it's a little disappointing that it doesn't mesh better.

I'm not a Python developer, though I use applications that require Python libraries. I don't want a separate numpy for every application I use tucked away in my home folder somewhere; I want a system numpy provided by my distro that can't get out of sync because there's only one copy of it anywhere.

[mikepurvis]

I think the Debian model is okay, it just falls down in terms of being able to have any kind of meaningful cooperation between the debs and what pip does, and of course there's the massive velocity mismatch between what's on PyPI and what's in your distro.... and of course no way to install more than one instance of something so heaven help you if you have two down-tree packages that depend on a different version of a thing.

Okay yeah no, even Debian pretty much sucks.

[p_l]

At the same time Nix implements python packaging particularly bad[1] when it does not have to. And that's on top of already insane state of python packaging. And poetry2nix becoming deprecated really bit me recently :/

Similar issues (minus insane packaging) is with Common Lisp packages, where there's annoying focus on compiling libraries into binaries (it would have been fine to have a bit of patching to provide things like correct paths for ASDF and CFFI search paths, but no....) which gives absolutely no benefit.

[mikepurvis]

I will say, there is one element of Nix's core design that makes almost all of these integrations considerably worse than they have to be, and that's the whole IFD fiasco— if it were possible to ingest an ecosystem-specific lockfile, run a build on it, and evaluate that result, then a lot of the drama and workarounds would melt away. This is sort of supported today, but it's basically banned from nixpkgs because of how the current implementation pauses evaluation any time it needs to run a build that evaluation is dependent upon... and it can only run one such blocking build at a time.

The new rust implementation (tvix) is addressing this as one of its core design goals, allowing evaluation and builds to run in parallel. But even once it's complete and usable, it's unclear what the relationship will be between tvix and Eelco's Nix.

[0x69420]

there is a very real sense in which nix has been riding on a good idea while ergonomics elsewhere in the field have advanced, yes. make no mistake, the technical work, getting programs to behave themselves in a fairly alien environment etc, has been impressive, but it's like in the marathon to get there, the idea of making that process somewhat nicer has been subject to constant procrastination. which sucks since in some sense the lay packager is working with the exact same tools as the people bringing the whole system together. not just nixpkgs dx has fallen down the list of priorities, but technical debt down to nix itself has accrued as well. the tvix effort emerged from dissatisfaction with instability (the same dissatisfaction that kept the actual version of nix used in a typical nixos install well behind master) well before any administrative/sponsorship struggle snuggle, and i still maintain that an effort more conservative in scope such as lix would have emerged politics aside, as again, what the end user sees switching to that is mostly "oh hey this random thing that repeated segfaults conditioned me out of attempting just... works now lol?" or various ux papercuts just ceasing to be. nix-at-large has a ways to go but i am optimistic

[bkiran]

Thanks for the perspective. I mainly use NixOS to run my server's not personal machines. I can see why it can be a frustrating experience for a machine that you just want to run personal stuff on.

In my instance of creating server machines(cattle), the configurations are pretty light and what's important is the reproducibility aspect of it. If I need to take one down and rebuild another it takes about 10 minutes. All the upfront work of configuring Nix for that one machine has paid off.

[sellmesoap]

I'm a big nixos fan myself, and I appreciate your post, I don't do any of the socials listed on your site and noticed the word 'serice' if you wanted some backseat editor. Apologies if hn comment in the wrong place for the feedback.

[bkiran]

Appreciate the feedback. Will edit the post and check for other grammar errors

[LorenzoGood]

> As a random example, I googled "packaging python for nix" and the top result [1] is just way too complex for something that should be pretty simple.

Aware that this is more of a critique about the documentation situation, as opposed to the python packaging situation. However, there is poetry2nix[1]. Which makes packaging look something like this:

    myPythonApp = mkPoetryApplication { projectDir = ./.; };

[1](https://github.com/nix-community/poetry2nix)(although it has been merged into nixpkgs master)

[p_l]

poetry2nix has actually been deprecated[1], and is in my experience subtly broken, as is the entire python packaging mechanism in Nix[2].

So we're now getting yet another attempt, this time called pyproject-nix[3].

I'm now considering taking similar stab with common lisp packaging, because the amount of time I lost fighting Nix trying to run a development environment is making me reconsider using Nix at all.

[1] https://github.com/nix-community/poetry2nix#:~:text=announce...

[2] https://pyproject-nix.github.io/pyproject.nix/build.html

[3] https://pyproject-nix.github.io/pyproject.nix

[LorenzoGood]

For a development environment, you could just pull in the poetry package from nixpkgs.

> I'm now considering taking similar stab with common lisp packaging.

For nix?

Also, thanks for contributing.

[p_l]

Yes - the complaints about python builders in nixpkgs apply as well to common lisp packaging even if implementation details differ

[from-nibly]

Nixos also makes deploying k3s a breeze. Even with etcd.

[Havoc]

Id definitely plan more than 2gb for a k8s node. The overhead is nontrivial.