[spijdar]

Building those applications consistently and reliably, e.g. being able to hop on a random Linux box and be able to build and deploy an application without thinking about where to fetch copies of all the dependencies. Nix’s raison d’etre is really to make developer lives easier, IMO.

I don’t use Nix, but I’ve played with other Linux package managers enough to understand the desire for something better, and something that’s actually predictable, especially (emphasis here!) when mixing/matching arbitrary versions of dependencies. I used Gentoo/Gentoo-derivates for several years and it (building random packages with == specific versions) is a sticky problem when using a traditional build system.

Of course, once the packages are built then you can do whatever hacks to bundle the dependencies with it. But the hard part is building them in a consistent, “reproducible” way.

[PaulDavisThe1st]

"build and deploy" are two entirely different tasks.

Both the macOS .app design, and various ad-hoc Linux packaging strategies deal with the deployment step in a relatively trivial, extremely non-invasive way.

The build step is something else entirely, and while I can imagine that for some projects what Nix offers has much value, for others the problem is solved by a permanently deployed build stack (or stacks) whose specificity goes beyond anything that a distro-managed system could offer.

[__MatrixMan__]

I think you're right that it's the build step where nix provides value. It's about replacing:

> a permanently deployed build stack (or stacks)

with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme.

But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package before you distributed it.

The idea behind NixOS is that since we must precisely define our build stack anyway, why not use the same technology to define the rest of our OS. Maybe that's overkill for some, but it sure is handy that there are NixOS users out there so when I want to use something from nixpkgs when defining my dev environment on MacOS it already has the kinks worked out.

As for

> ...whose specificity goes beyond anything that a distro-managed system could offer.

My feeling is that most nix code is not distro managed but rather written by individual project maintainers. We only bother contributing something to nixpkgs if we think it's widely applicable.

[PaulDavisThe1st]

> with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme.

> But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package before you distributed it.

This suggests to me that either you don't know how .app packaging works on macOS (or various ad-hoc packaging on Linux, such as Firefox or Ardour), or you're making a point that I'm missing.

The whole point of these non-Nix systems is precisely that you just package up bits of the build stack into the thing you distribute, and you reduce or eliminate system dependencies other than such basics as the system C library or X11.

[__MatrixMan__]

I had misunderstood what a .app package was, thanks for clarifying. So do people package things like linters and language servers into the .app also? Like, is it everything I'd need to work on the app, or is just everything I'd need to run the app?

[PaulDavisThe1st]

Everything needed to run the application.