Major problems: installing niche proprietary software that you may have to package yourself, and fighting Nix for languages with package manager, e.g. Python, which frequently uses packages not in nixpkgs.
And if you do put in the effort to make a package, you'll never have problems figuring out how to install it in the future, and can share that gain with others.
Making packages for nix is way easier than making debs or rpms in my experience.
It’s not elegant, but you can also usually find popular Python libraries in nixpkgs so they’re available in your shell’s “global” Python environment.
The nix language itself is pretty straightforward and if you know haskell your should feel straight at home.
You shouldn't use nixpkgs python packages as a replacement for your python development. That would also not work that great on other distros.
Yes, but that still doesn't solve this:
> Major problems: installing niche proprietary software that you may have to package yourself
If some software _isn't_ packaged, it's a pain in the butt to get it running on NixOS. Either you have to create Nix derivations, which have a pretty steep learning curve, or you have to do some hackery patchelf business, which also isn't easy.
At least, as of 2018, when I last tried. Things could be better now.
You almost never want to invoke patchelf by itself but use some wrapper like autoPatchelfHook, FHS, nix-ld, nix-autobahn, etc.
Since 2018 a lot quite a lot happened. Give it another chance.
The unfortunate part is that creating a Nix derivation is no more approachable than the patchelf hackery was in the first place.
So what does this get us? In theory, this is now trivially-buildable on any distro that has nix installed, or on nixos. I haven't converted it to a flake yet (still learning that) but if I (or someone else) did, it would be deterministically reproducible anywhere on nix.
I agree that there's a learning curve on figuring out the "recipe" for a thing, but once someone does that work, it's basically done forever. Which is a promise that no other system can even approach.
And once you figure out a certain amount of it, this moment will come where you realize you want every system you deal with to be Nixified. Like the guy elsewhere in this thread who rebuilt his own router using NixOS and loves it.
Getting new developers up to speed in your shop's dev environment? Completely trivial to do with Nix. Getting a machine back up after a failure? Reinstall NixOS and reapply the config you were using (which is in source control). Upgraded Gnome and some things you need broke? Or updated your GPU driver and now your screen just shows black? Simple... Roll back in the bootloader to a previously-working config, then undo your changes to the config definition.
Have 10 different projects all with different dependencies and version requirements that would normally collide with each other? Trivial, each project has its own default.nix file and Nix can drop you right into that environment while you're working on those projects.
NixOS (and very honorable mention to Guix) are in fact the only ways to run Linux while keeping your sanity intact!
If there's some easier way, I'm eager to hear about it.
1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look for when you got an error. If you only know haskell, you may not know this.
2. If you wrote the correct script, it just works. But if you wrote something wrong but syntactically correct, finding the issue may not be that trivial, in my experience the trace is not very useful.
3. Not sure where the documentation for helper functions is. I think there are unofficial documentation out there but iirc it is not in the nix reference manual?
4. Some python packages with system dependencies will not work when installed through virtual environment. I haven't done serious python development for a long time so I forgot what I usually do to fix it, but I think I just packaged everything in Nix.
5. Some build tools without wrapper (iirc mold, ldd) will cause loader error.
But yeah, I do agree that packaging is not that hard, just require a bit more thoughts than just using typical build instructions and `make install`, and perhaps look at the binaries with ldd.
3. For example here https://nixos.org/manual/nixpkgs/unstable/#chap-hooks
5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.
So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)
And if you don't have any FP background you're just.. out of luck. /s
As for last problem.. Yeah. It is a problem. x.x
I don't think I agree here. There are plenty of examples of how to package/update/fix anything custom you desire. The learning curve is there, definitely, but this is not major - I do this several times for my own OS and software that utilizes Nix.