[speed_spread]

Yup, the versions of the toolchain components required for a project to build should be specifiable at the project in an format actionable by the main build tool. Running a project should never require more than "git clone $project && $build-cmd".

It should never be Nix's business (or any other OS) to provide elements of a project's toolchain. Reciprocally, projects should go out of their way to not depend on OS installed toolchain components.

[mixedCase]

> It should never be Nix's business (or any other OS) to provide elements of a project's toolchain.

Why? I used to think the same way, but that's because of the scar tissue of all the tooling being terrible at accepting that build concerns and packaging concerns are one and the same.

Nix proves it and makes this ancient pain a non-issue: "My package depends on x, y and z, additionally, building it requires a, b, and c, please also make build dependencies available in my shell while I write code too". That's it.

> Running a project should never require more than "git clone $project && $build-cmd".

That's precisely what Nix allows you to achieve. Meanwhile doing this:

> Reciprocally, projects should go out of their way to not depend on OS installed toolchain components.

Means that you can never depend on anything you're not vendoring (read: maintaining a copy of, on your own). Or it means sacrificing productivity in the altar of shitty tools. Nix allows you to have your cake and eat it too.

[speed_spread]

Shared projects should not depend on a particular package manager. You may use Nix, but the next person might use something else because reasons. If you bind a project's lifecycle to a specific OS you'll be trading your convenience for those of others.

[mixedCase]

Nix, the package manager, is not an OS nor is it locked to one distro: it runs on any Linux distro, it natively runs on macOS, and it runs on WSL.

It is also not a package manager like "apt", "dnf" or "pacman" as it does not fill the same niche. It does not even have to fill the same niche on every project.

As an example: at my job we're using it exclusively for optionally managing shared developer dependencies. Everyone is free to manage their own dependencies if they don't want or can't use Nix. But a flake.nix is there so you can get everything configured for you automatically.

In a personal shared project of mine I use it for tracking developer and build dependencies, meaning that I can build the project through Nix without having any of the dependencies specific to this project installed globally on my machine, meaning I can work on other projects that use incompatible versions of the same library, and keep the project reproducible.

On my desktop and laptop I use it as part of NixOS (which is an OS), to configure both from a single, mostly-shared configuration I keep in Git, replacing a mountain of terrible Ansible and shell scripts that did not work even nearly as well.

You can also use it to generate Docker images, operating system ISO images, distribute your app as an AppImage, Snaps,... and many other things. And you get an actual programming language to do all that with all the tooling the community maintains for each usecase.

If you're just using it as an asdf replacement, as the comment you originally replied to compared it to, your project will not be any more locked in to Nix than it would be to asdf.

[speed_spread]

I see your point and will give the concept of Nix-as-a-build-platform-manager some more thought when imagining the "ultimate build system", something which comes to me every few weeks.

[viraptor]

I think you're missing the point of nix. Unlike other systems, yes you can make it mix's business to provide that. And the threshold for "OS installed" becomes blurry enough that projects can include the definition of what they depend on from the system.

[speed_spread]

You're missing my point, that building a public project from source should not require you to have a specific package manager installed.

[viraptor]

I don't believe there's any non-nixos project so integrated with nix that it's required. You'd need to show some example here. It's normally just a wrapper for the description of how to setup the system - which you can totally do on your own and that's how most projects roll: just a text description of dependencies / versions.

[rgoulter]

"project should be able to be built without nix" is reasonable.

"Nix shouldn't provide compiler toolchain" is not.

Nix's whole design is oriented around explicit description of inputs in programmatic descriptions of package.