[spease]

> While Nixpkgs is an amazing resource, Nix != Nixpkgs. Nixpkgs is highly unideal for cases where you want to be able to pull arbitrary versions of toolchains, but it is not the only way to go. For example, there is amazingly good Nix tooling for pulling an arbitrary version of Rust. Other Nix-based developer tools have shown how you can do this well.

It’s so exhausting that every single time a basic use issue comes up with nix, the response is “but there’s a way to work around it (that you need tribal knowledge for and will require writing dozens to hundreds of lines of code to fix in a language that doesn’t work like any of the mainstreams with bad error messages and poorly documented standard libraries)”.

People’s problems with nix are not that it isn’t turing-complete, it’s that it often creates more problems than it solves by refusing to provide a simple first-class API that interoperates with idiomatic projects in that ecosystem that just works.

If every project you try to use nix for devolves into centering around trying to fix issues with nix that you have to write your own modules for, why even bother using nix instead of mainstream tools with good documentation? Exactly what happened in this case. In most cases people are probably just deciding to use docker instead.

Nix’s refusal to address practical developer experience issues for a developer-facing product on a non-geologic timescale in favor of ideological pure flakes is rather frustrating.

Yes, people are contributing their own time, but it’s so damn frustrating to see so much technical effort going into something that’s rendered practically unusable because of bad UX.

[__MatrixMan__]

You can use nixpkgs as a single versioned input, and you can also give certain things their own distinct input to be tracked separately in flake.lock, but I wouldn't describe either as a "workaround" for the other.

It is a bit of a headache to have to pick which mode you want for each dependency, but I'm not sure that's a headache that can be dispensed with via UX improvements.

> why even bother using nix instead of mainstream tools with good documentation?

nix lets you have a single source of truth for all of it. It's not nix vs apt or nix vs pip, but rather nix vs (pip & (apt|brew)).

So far as I know, the only other tool that scratches that itch is bazel, otherwise you're kind of stuck with multiple overlapping packaging strategies that don't communicate, which is a recipe for "works on my machine".

[jchw]

> It’s so exhausting that every single time a basic use issue comes up with nix, the response is “but there’s a way to work around it (that you need tribal knowledge for and will require writing dozens to hundreds of lines of code to fix in a language that doesn’t work like any of the mainstreams with bad error messages and poorly documented standard libraries)”.

> People’s problems with nix are not that it isn’t turing-complete, it’s that it often creates more problems than it solves by refusing to provide a simple first-class API that interoperates with idiomatic projects in that ecosystem that just works.

Well, first of all, this article isn't even about the UX of using Nix directly, it is about Nixpacks, a tool built on top of Nix. If Nix already solved the problems Nixpacks were trying to solve, they would've had no reason to write it, so I don't really see how this could be relevant.

> If every project you try to use nix for devolves into centering around trying to fix issues with nix that you have to write your own modules for, why even bother using nix instead of mainstream tools with good documentation? Exactly what happened in this case. In most cases people are probably just deciding to use docker instead.

Would it matter if there was good documentation if you were not willing to read it anyway? Both of the issues I talked about actually are covered in the official Nixpkgs documentation and have been for years. For example, here is some of the documentation for layered docker images:

https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...

Nixpkgs and NixOS are maybe not perfectly documented, but on the other hand, they're absolutely enormous projects. The documentation that does exist is already staggering. And of course it is! Seriously, try finding a singular project that has as big of a scope as Nixpkgs...

Of course, what people seem to read from what I said is that Nix is actually perfect and there are no problems, but what I'm really saying is they didn't go into very much detail on how they tried to solve the issues they ran into. The two possibilities are that they didn't try very much, or that they did and they omitted it. The latter is certainly as plausible, but it leads to this confusing problem where their complaints don't really make much sense on their own. What I am talking about is not obscure bespoke tribal knowledge. It's pretty close to the first stuff you would learn if you read docs or tutorials.

> Nix’s refusal to address practical developer experience issues for a developer-facing product on a non-geologic timescale in favor of ideological pure flakes is rather frustrating.

> Yes, people are contributing their own time, but it’s so damn frustrating to see so much technical effort going into something that’s rendered practically unusable because of bad UX.

This really seems like it's veering far away from the discussion about Nixpacks and into personal grievances about Nix, but honestly there's thousands of build systems and package managers that don't work the way Nix does, I do not really see why Nix should compromise its ideals. for the sake of UX. But please don't get me wrong: I agree on the point that Nix has a worse UX than it could; I think the language is full of unneeded papercuts and confusing things and meanwhile the time it has taken to stabilize flakes and the new Nix command has really been a drag and introduced a lot of confusion. On the other hand, though, I'm not even sure it's worth wasting too many tears over this: as hard as it is to get started in Nix and as many things as there are that could be improved with Nix and Nixpkgs itself, really the chief pain I feel when dealing with anything involving Nix is not Nix itself but the world it exists in.

Nix has existed for over 20 years and in those years the world of OS design and package managers only really started to move towards immutability and purity relatively recently. Most software still likes to have tons of mutable, impure shared state and trying to encapsulate this into Nix can be very painful. Nix has grown many limbs and improved in many ways to try to deal with this, but it is still far and away one of the biggest sources of confusion that I have with Nix.

It is not a given that things have to work this way, but it is a natural consequence of the fact that Nix is trying to do something that is very much at odds with the way software has worked for a very long time. The impedance mismatch is massive and unavoidable, but I don't think the answer is that Nix should bend to deal with this. If someone finds what they feel is a better sweet spot between what Nix is today and the world outside of Nix, they should feel free to pursue that, but I'm involved with Nix because I think it has the right ideals just way too early.

Having dealt with systems that try to be hermetic like Bazel, you can certainly get some meaningful benefits from sitting at a midway point, but what we're chasing are the benefits you get much closer to the end-game of hermetic systems, when hermeticity is enforced strongly across the entire system. This is about more than just being a convenient tool for developers and much more into the future of how systems are designed. And yeah, sure, when you try to build on top of this in today's world, it can be awkward, nobody is denying that, but a lot of this awkwardness is, unfortunately, a feature, and while clever Nix solutions may eventually exist for some of those problems (a lot of clever work is being done, with concepts like dynamic derivations) I really feel strongly that you shouldn't hold your breath.

And sure, by all means, switch to OCI tooling if you feel like it works better. It may very well actually be better for some use cases! But you literally can not replace most of what Nix is used for and can do with OCI tooling, it's ultimately a very small subset of what Nix is capable of overall.

[hnaccount_rng]

I’m very sorry. But for a person that tries to get into Nix this reads like pure gaslighting. I haven’t even found an official description of what Nix vs NixOS vs nixpkgs tries to achieve vs what they do not want to achieve.

There is a near infinite collection of blog posts what people use Nix for. All full of Nix-internal jargon derisively critiquing alternative (that do in fact actually work) without ever coming out and laying the groundwork for what the underlying problem is _and what the solution to that is_.

I think that I would end up liking Nix in principle. I really did enjoy the Spack package management system and I do think Nix is doing things reasonably similarly (everything is Nix, all inputs are securely provided, reusing things as much as possible).y current problem is taking a homelab server into “production” and all I really want is a way to write down a state I want the services on it to be in, have that in a git repo and be able to regenerate this server after loosing it (in a first step without any data backup). I’m still, after 2 months (wall clock, call it maybe 3 days actually getting into this project), not sure if that’s a thing Nix tries to cover! (I think it does, but..)

[flurie]

A lot of work about packaging specifics reads like inside baseball because it is. Most people manage to avoid getting into the specifics of packaging because it’s stuff that mostly gets in the way of the problem they’re trying to solve. But for blessed few packaging is either critical to the problem or is the problem itself. If you never had to learn the inside baseball terminology, it is likely that packaging is not critical to problems that you solve, and I say that without judgment. If you need to get into Nix, you will. There are lots of reasonable ways to manage personal infrastructure that don’t involve Nix. For the problem you describe, I’m not even sure Nix is a preferable solution unless you already use it.

That said, I agree with the original comment. I’m willing to believe that they had these problems and that moving away from Nix was the right decision, but there is little detail in the explanation. They’ve been pretty closed users of Nix to my knowledge, building proprietary tools on top of it without contributing back significantly, and it feels like orgs such as repl.it are contributing back more actively, but this may be a marketing difference as well.

[hnaccount_rng]

I spend significant parts of my PhD maintaining the packaging and deployment infrastructure of our group. But yes, I have close to no computer science and reasonably little intrinsic interest in the problem space (though I have a deep appreciation). Still I think I have a better than average understanding of the packaging space..

[jchw]

I think you may be overthinking things. In brief;

Nix is two things: a functional programming language called Nix, and a package manager written in C++ that compiles and installs packages written with Nix expressions. Nix the language itself, and it's implementation.

Nixpkgs is a repository of Nix packages. It also contains NixOS, which is also just a bunch of Nix.

NixOS is a Linux-based operating system built on Nix. It is configured using NixOS modules, a configuration system of sorts built on top of the Nix programming language. A NixOS system is literally a single big Nix package built from NixOS modules that depends on a bunch of other packages.

If this still seems too complicated it would probably be better to just dive in and mess with it so you can physically see what's going on.

> current problem is taking a homelab server into “production” and all I really want is a way to write down a state I want the services on it to be in, have that in a git repo and be able to regenerate this server after loosing it (in a first step without any data backup). I’m still, after 2 months (wall clock, call it maybe 3 days actually getting into this project), not sure if that’s a thing Nix tries to cover! (I think it does, but..)

Yes that does sound like something NixOS can cover. Obviously, you will still need backups for your mutable data (databases, files, etc.), but if you are able to encapsulate the entire setup of a server into a NixOS config you can indeed throw a machine out the window and have a new one set up and booting the exact same services in minutes.

This is pretty much the original thing that drew me into NixOS, especially because at the time I was highly interested in qemu GPU passthrough setups and I really liked how with Nix all of the complicated setup bits could be expressed in a single file, with about 20 lines of Nix, all accounted for and version controlled. A lot better than just hoping you remember to keep things documented.

I won't lie, learning NixOS and using it for a real machine setup was very painful for me at first. I struggled with many things over time. Still, I really think because the scope of things these projects do is huge it's really easy to overcomplicate things. All of the explosive scope of Nix comes from relatively simple primitives applied in large systems.

I really don't want to encourage people to suffer with Nix if they feel like it's just too convoluted and hard to work with. I am not trying to convey that Nix is simple or easy on the whole. I was only ever trying to explain why I felt the issues raised by this post were confusing to me, not trying to tell people that Nix is generally easy. I think a lot of replies genuinely continue to misunderstand this, but the point of saying that it's easy to do that in Nixpkgs is not to dunk on people who struggle with Nix, it's to say that it's not clear why Nixpacks would struggle with these particular issues. You can literally just split the /nix/store paths into separate OCI layers. There is no obvious reason why this strategy can't be used, and the blog post doesn't go into the background behind it. I bet there actually is background, it's just left unsaid.

[hnaccount_rng]

I think I got the first part, including and up to

> If this still seems too complicated it would probably be better to just dive in and mess with it so you can physically see what's going on.

And it really seems like NixOS being _the_ correct :tm: solution for what I want from an home server. The problem is that Nix doesn't quite cover (or at least didn't when I first deeply looked) my needs (it lacked a useful Clickhouse package). And I don't even want to say "Nix should be simpler". I don't even think it _can_, it's fundamentally a complicated and complex problem to deal with!

My problem is solely with the Nix community. The amount of jargon-loving and argumentative "you shouldn't attempt what you are attempting in the first place" or "you are holding it wrong" gaslighting is really something :D

I think the point where you fail to grasp the problem is: Nobody is claiming that Nix can't do a thing. My complaint is: There is no way to find _the_ way to do the thing. And there seem to be multiple _incompatible_ ways to achieve any given state. Without any way to distinguish those (let's call them) camps for a new person. In this way it's everything Unix but dialled to eleven! You don't need to argue (for me) that anything _can_ be done. I'm getting that from "Turing complete". My problem is only the practice: How do I get there?

edit: I think my immediate problem is: How do I get the series of "commands" that a nix derivation will invoke? Kind of like "what's the receipt, that is being executed?" That's missing for a sensible repl-loop for me. I'm sure I'll be getting there. The capability that Nix offers is extremely appealing. But at the same time the documentation and community are unhelpful to the extreme

[jchw]

> My problem is solely with the Nix community. The amount of jargon-loving and argumentative "you shouldn't attempt what you are attempting in the first place" or "you are holding it wrong" gaslighting is really something :D

> I think the point where you fail to grasp the problem is: Nobody is claiming that Nix can't do a thing. My complaint is: There is no way to find _the_ way to do the thing. And there seem to be multiple _incompatible_ ways to achieve any given state. Without any way to distinguish those (let's call them) camps for a new person. In this way it's everything Unix but dialled to eleven! You don't need to argue (for me) that anything _can_ be done. I'm getting that from "Turing complete". My problem is only the practice: How do I get there?

I honestly have relatively little experience with the majority of the Nix community, so I can't speak too much to it. I did not personally experience too many problems.

The frustrating thing to me about this thread is that it definitely wasn't in this vein. I know I'm harping on this a lot, but it matters.

What the blog post says is "we can't split the image into multiple layers with Nix". And again, they're doing their own OCI building, so this actually has little to do with Nixpkgs and is much more conceptual in nature. If you build a Nix closure, what you wind up with is a number of store paths. For example, for bash, you might have the following store paths:

    /nix/store/za53jjhjl1xajv3y1zpjvr9mh4w0c1ay-xgcc-14.2.1.20250322-libgcc
    /nix/store/yypqcvqhnv8y4zpicgxdigp3giq81gzb-libunistring-1.3
    /nix/store/6nkqdqzpa75514lhglgnjs5k4dklw4sb-libidn2-2.3.8
    /nix/store/cg9s562sa33k78m63njfn1rw47dp9z0i-glibc-2.40-66
    /nix/store/xy4jjgw87sbgwylm5kn047d9gkbhsr9x-bash-5.2p37

So how do you split these into layers? Well, however you want. You can place them into individual layers, or you can group them based on dependencies to make more "logical" groupings and get less layers, or basically any number of things. There's plenty of metadata on what depends on what, so it's really up to you to decide how to do that.

I was not talking to end users when I said this, I was talking to developers building on Nix that almost definitely knew this. So it's unclear based on what they said why they couldn't.

> edit: I think my immediate problem is: How do I get the series of "commands" that a nix derivation will invoke? Kind of like "what's the receipt, that is being executed?" That's missing for a sensible repl-loop for me. I'm sure I'll be getting there. The capability that Nix offers is extremely appealing. But at the same time the documentation and community are unhelpful to the extreme

I see.

Well, for starters, you are trying to start at the very low-level bottom of the stack. I understand this because it is the approach I prefer to take when learning new technology, but I'm telling you right now this is a hard road to go down with Nix, I've been down it. The documentation is going to continue to feel unhelpful because you will find plenty of documentation that is happy to take you down the dark paths of how things actually work, but that doesn't make them any easier to navigate. It's much easier to start by asking "how do I accomplish this end-goal" than to ask "what actually is a derivation".

With that out of the way... to understand what's going on with builds, you really genuinely do need to know what a derivation is, because it matters. Almost nobody calls the `derivation` function directly in Nix, instead using Nixpkgs mkDerivation tool at the bare minimum, but at the very bottom, there is only one function that matters:

https://nix.dev/manual/nix/2.22/language/derivations

At the bottom, in order to actually build something, a derivation has to be evaluated and realized. Internally, instantiating a derivation will cause it to be built. It is built by taking the parameters passed to derivation and serializing them to an internal format, then "instantiating" it, causing it to be built inside of the sandbox. The internal derivation format looks like this:

    Derive([("debug","/nix/store/xsxanvyy93g3k5dnh0j2wisrwvq012b2-bash-5.2p37-debug","",""),("dev","/nix/store/lnzar8zawj43wkqlsdqhywda9hjymrgf-bash-5.2p37-dev","",""),...

Basically a lot of arrays and tuples and whatnot. Not very easy to read. `nix derivation show` can give us better human-readable output:

    {
      "/nix/store/rfkzz952hz2d58d90mscxvk87v5wa5bz-bash-5.2p37.drv": {
        "args": [
          "-e",
          "/nix/store/vj1c3wf9c11a0qs6p3ymfvrnsdgsdcbq-source-stdenv.sh",
          "/nix/store/shkw4qm9qcw5sc5n1k5jznc83ny02r39-default-builder.sh"
        ],
        "builder": "/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash",
        "env": {
          "NIX_CFLAGS_COMPILE": ...

So what does `nix build nixpkgs#bash` do? Well, aside from the sandbox setup, on my particular machine, it would run... /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash -e /nix/store/vj1c3wf9c11a0qs6p3ymfvrnsdgsdcbq-source-stdenv.sh /nix/store/shkw4qm9qcw5sc5n1k5jznc83ny02r39-default-builder.sh. So, basically, a bash script. What does that bash script look like? Here's the entire contents of default-builder:

    genericBuild

This is in the heart of the Nixpkgs "stdenv" machinery, and now we're outside of what Nix itself does and into what Nixpkgs does. Literally all Nix does is handle the book-keeping: sandboxing, execing the builder, handling the Nix store; for the actual build, it is just execing the builder, and in most cases, it will wind up being handled by a bash script. You could have whatever builder you want here, of course, and it needn't be bash or bash-based. (Note that we're calling bash to build bash - funny choice for me to pick, but you can see how it gets the copy of bash to build bash with from a special derivation called bootstrap-tools. Gotta break the cycle somehow, and Nix doesn't have as impressive of a bootstrap seed as Guix.)

So, for this build, it just calls genericBuild. What does that do? Well, you can keep chasing down the scripting here, but ultimately it calls all of the build phases, e.g. unpackPhase, patchPhase, configurePhase, buildPhase, checkPhase, etc. which are all just bash scripts inside of environment variables. At the end of the day, it does roughly what you would do to build bash, plus some patches. The nixpkgs stdenv automation helps handle many special Nix things, but it's not actually horribly complicated.

By the way, when you see this sort of thing in a Nixpkgs derivation:

    patchPhase = '''
        ...
    ''';

It is in fact just setting up environment variables. You can see them in `nix derivation show`, even. They get called just by substituting them directly into a command, not any different than:

    test="echo Hello world" bash -c "$test"

Basically, all of the attributes in the mkDerivation call become environment variables, including src, and all of the magic that gives them meaning is just in the stdenv default builder. (This is roughly true, anyway. I think there is some move to make it "stricter" but the default way it works is still like this roughly.)

So how can you debug what actually happens when building a derivation? Unfortunately it's not terribly easy. You can view the logs with `nix log`, but it will only show one if it actually built it, not if it substituted it from Hydra cache for example. Also, the default behavior of the builder doesn't output that much diagnostics, though you can add NIX_DEBUG = 7 in a derivation and it will output tons of information about what is being executed.

The way derivations depend on other derivations is something like this:

- During build-time, when you try to coerce the result of the derivation function to a string, what gets returned is the realized store path. So if I try to do `${pkg.bash}/bin/bash` inside of Nix, it might return `/nix/store/xy4jjgw87sbgwylm5kn047d9gkbhsr9x-bash-5.2p37/bin/bash`. In this way, it is natural to literally just depend on something implicitly by realizing it as needed.

- As far as I know, for runtime dependencies, it is detected by literally scanning the $out directory after a derivation is built and looking for the Nix store paths of other derivations. Merely realizing a dependency during build-time won't make it a runtime dependency.

It's more complicated than this, but that's the broad strokes. So when you build bash, it will implicitly depend on all kinds of build tools like GCC and make, but the resulting derivation will only depend on things like libgcc that are actually referenced in the final derivation.

Honestly, it is a bit of a black box. It is not easy to navigate. Trying to learn Nix from the ground up first will be very hard. I wouldn't ever tell someone not to try, but I will definitely say it won't be easy.