And you can do that in theory, but in practice it ends up like this:
- you want to use lang-x.y.z, so you'll just reference an old commit
- turns out that version was never packaged, so you copy x.y.z-1 to your flake/overlay
- you end up patching the build because it doesn't work by default with new environments
- on the other hand a module you're using needs the new environment so you do your best to make everything happy - more overlaying
- because you changed something crucial in a few steps, you're compiling llvm 20 times through this process and now it's 1am
Compare that to putting "rust 1.59" in your .tool-version and running "asdf install". Guess who tried to use 3 specific versions of rust at the same time recently and got very familiar with the process...
(That's also ignoring the issue like Ruby being packaged without the platform identifier in nix which makes it unusable for some development purposes)
If it's Rust, you can use https://github.com/oxalica/rust-overlay to get any version you want very easily without pinning an instance of nixpkgs just for it.
asdf does not allow you to keep three different versions of the same language, so I'm not sure how that compares? It's not super-trivial to do in Nix, but at least you can do it.
asdf is also no different than Nix when it comes to minor/major versions. You're at the mercy of what the plugin does, other than that you have to create your own plugin from scratch or make a fork. Nix has the option to patch things up more easily at least.
> asdf does not allow you to keep three different versions of the same language
Sure it does. You can have any number installed and either switch by changing the tools version file, setting it for your shell, or referencing the right path directly.
> You're at the mercy of what the plugin does
Again theory vs practice. In theory, sure, it depends on the plugin. In practice, almost every plugin lists every single released version to choose from. Which is much different from nix where the official choices are limited and you have to work to enable the rest.
> You can have any number installed and either switch by changing the tools version file
Oh, that's cheating :) Nix can do the same thing! Derivations are just kept in the store until you garbage collect them. You can also configure multiple versions at the same time to present you with multiple binaries, which is what I was referring to.
> Again theory vs practice. In theory, sure, it depends on the plugin. In practice, almost every plugin lists every single released version to choose from. Which is much different from nix where the official choices are limited and you have to work to enable the rest.
In practice, nixpkgs supports every maintained version of most tools. Certainly far more tools than asdf can ever hope to maintain. If not, there's an overlay or flake out there to support it. Can you come out with specific examples and a usecase?
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.
> 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.
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.
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.
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.
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.
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.
- you want to use lang-x.y.z, so you'll just reference an old commit
- turns out that version was never packaged, so you copy x.y.z-1 to your flake/overlay
- you end up patching the build because it doesn't work by default with new environments
- on the other hand a module you're using needs the new environment so you do your best to make everything happy - more overlaying
- because you changed something crucial in a few steps, you're compiling llvm 20 times through this process and now it's 1am
Compare that to putting "rust 1.59" in your .tool-version and running "asdf install". Guess who tried to use 3 specific versions of rust at the same time recently and got very familiar with the process...
(That's also ignoring the issue like Ruby being packaged without the platform identifier in nix which makes it unusable for some development purposes)