Nix and NixOS, my pain points
remy.grunblatt.org
Nix and NixOS, my pain points
1–10 of 109 posts
Re: Nix and NixOS, my pain points
#2I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home.
Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun.
I like the outcome, and I’m glad I took the time now, but it was a slog that I don’t think I could really recommend to any of my peers.
It’s too bad guix went full hardcore FOSS and refuses to support macs, because they seem to have better docs and using a language that I can use outside of my package manager makes a lot more sense to me.
Re: Nix and NixOS, my pain points
#3I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home. Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun. I like the outcome, and I’m glad I took the time now, but it was a slog that I don…
I keep reading, this, and keeping being told this. Yet I switched every system over to nix and have found no thing but the best examples documentation and help from nix to do so.
Within the span of a afternoon and a bit a reading I went from zero, to a script that lets me setup an entire dev systems with just a few commands in a vm, and or even on hardware.
If anything the Nix documentation is just as good as every other thing out there. What is different is there are more than one way to do many things in Nix. This to me I think is the core of complaints. Its a language, and thus the language has may expressions that result in the same outcome.
The second bit I think people struggle with is it is functional. If you look at Nix complaints they appear to nearly be identical to that of Haskell.
Re: Nix and NixOS, my pain points
#4I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home. Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun. I like the outcome, and I’m glad I took the time now, but it was a slog that I don…
I agree with the Guix bit. At some point, I tried using Guix System on my laptop (with wireless support), and of course I was greeted with « use a wifi card that respect your freedom » or something of the sort.
At some point, I might try again, using NonGuix ( https://gitlab.com/nonguix/nonguix ), but right now I'm not using Guix SD. Instead, I try to use Guix on small projects (like building websites using pelican), without going full Guix.
What I'm most impressed with Guix is the time machine and Software Heritage integration, but it still needs a lot of improvement for developers, for example allowing to specify environment variables in manifest.scm files.
Re: Nix and NixOS, my pain points
#5I've only used nix at home for 2 months but my biggest pain point is just dealing with testing out random GitHub projects where I need to install dependencies from some language's package manager.
There is usually a nix way, but I don't wanna build a custom nix script every time I want to test something out.
However I found that using distrobox solves this problem for me quite well. It's a way to easily create and enter another distro from the terminal while it inherits everything else from the host.
So whenever I want to try a random python project I just do it there and don't care about making a mess, while my host system is clean.
I'm sure there are better ways to do these things, but I can't seem to find answers that don't seem to involve a lot of work.
Re: Nix and NixOS, my pain points
#6> When we use NixOS, and we want to use a package that is not available under NixOS / Nixpkgs (which happens quite often), we have only one choice: pack it into NixOS.
That's not the only way. It's definitely the easiest option, but you can also create a temporary fhs environment https://github.com/ElvishJerricco/nixpkgs/commit/05742c15d5a...
Re: Nix and NixOS, my pain points
#7I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home. Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun. I like the outcome, and I’m glad I took the time now, but it was a slog that I don…
I keep reading, this, and keeping being told this. Yet I switched every system over to nix and have found no thing but the best examples documentation and help from nix to do so. Within the span of a afternoon and a bit a reading I went from zero, to a script that lets me setup an entire dev systems with just a few commands in a vm, and or even on hardware. If anything the Nix documentation is just as good as every o…
I also didn't notice that the documentation was especially bad. I'm thinking maybe it makes more sense for some programmers?
Re: Nix and NixOS, my pain points
#8I've only used nix at home for 2 months but my biggest pain point is just dealing with testing out random GitHub projects where I need to install dependencies from some language's package manager. There is usually a nix way, but I don't wanna build a custom nix script every time I want to test something out. However I found that using distrobox solves this problem for me quite well. It's a way to easily create and en…
There is a simple way, that is sadly not known enough: FHS environments.
https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...
Re: Nix and NixOS, my pain points
#9I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home. Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun. I like the outcome, and I’m glad I took the time now, but it was a slog that I don…
I agree with the Guix bit. At some point, I tried using Guix System on my laptop (with wireless support), and of course I was greeted with « use a wifi card that respect your freedom » or something of the sort. At some point, I might try again, using NonGuix ( https://gitlab.com/nonguix/nonguix ), but right now I'm not using Guix SD. Instead, I try to use Guix on small projects (like building websites using pelican),…
> for example allowing to specify environment variables in manifest.scm files.
There is already .envrc or .dir-locals.el? And manifest is just - well - manifest. By definition it has to be 'plain'. I mean, there are already a million ways to load env vars so why'd you want guix to do that too and from manifest.scm of all places?
Re: Nix and NixOS, my pain points
#10Earlier quoted context omitted.
I agree with the Guix bit. At some point, I tried using Guix System on my laptop (with wireless support), and of course I was greeted with « use a wifi card that respect your freedom » or something of the sort. At some point, I might try again, using NonGuix ( https://gitlab.com/nonguix/nonguix ), but right now I'm not using Guix SD. Instead, I try to use Guix on small projects (like building websites using pelican),…
> for example allowing to specify environment variables in manifest.scm files. There is already .envrc or .dir-locals.el? And manifest is just - well - manifest. By definition it has to be 'plain'. I mean, there are already a million ways to load env vars so why'd you want guix to do that too and from manifest.scm of all places?
Because instead of distributing two files (channels.scm and manifest.scm, or flake.lock and flake.nix), you have to execute monstruosities like `guix shell --container -m ./manifest.scm -- bash -c 'GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale LC_ALL=fr_FR.utf-8 exec jekyll build'`, which is how I build some websites I have.
To me, that's not ok from an user experience point of view.