3 ms·

As a fish user on NixOS, I'd say nix is still worth looking at. The fish-related issues came from trying to manage the whole of the fish configuration with Nix

As a fish user on NixOS, I'd say nix is still worth looking at. The fish-related issues came from trying to manage the whole of the fish configuration with Nix. I think that's a fairly niche thing to want to do.

0cf8612b2e1e 3y ago
But isn’t that the Nix promise? That I can have a fully reproducible system defined by a few configuration files?
- jahsome 3y ago
  What I've come to realize is while yes nix leads to absolutely bullet proof "reproducible" environments, there is seemingly very little care or thought about anything that comes before the build, i.e. the user experience for creating a configuration.
- rgoulter 3y ago
  Generally, Nix's strength is allowing for reproducing software behaviour, yeah. I'd say NixOS's declarative config more/less covers the config files, where on non-NixOS you'd edit the files under /etc (and hope you didn't break anything). Whereas, Home Manager's declarative config is more/less the stuff underneath $HOME or the XDG config dir. Turns out that a few things with fish shell don't work with a purely declarative config. (e.g. the universal environment variables are stateful). For myself, I don't rely on writing all my configuration in Nix files. I configure fish shell using config.fish. (Though I do use HM to symlink the config file).
- temptemptemp111 3y ago
  [dead]
- unshavedyak 3y ago
  re: everything in Nix, i use normal configuration most of the time. Ie with Home Manager, i just have Nix copy (link) my config files to the place apps look for them. I only would even consider recreating them in Nix if i needed programmatic construction of them or if i was trying to distribute them as a Nix package or something. But for just me, and my own use - i see zero reason to recreate config files which are already managed by Nix. It's just extra work with no benefit as far as i can tell. Especially because i detest the Nix language. It also makes it very difficult to search for, because if you want to figure out how to configure X feature of Y app, you need to search for that and then mentally map it to Z Nix configuration which may or may not support it. It's just layers of needless abstraction for a single-use configuration.

0cf8612b2e1e 3y ago

But isn’t that the Nix promise? That I can have a fully reproducible system defined by a few configuration files?

jahsome 3y ago
What I've come to realize is while yes nix leads to absolutely bullet proof "reproducible" environments, there is seemingly very little care or thought about anything that comes before the build, i.e. the user experience for creating a configuration.
rgoulter 3y ago
Generally, Nix's strength is allowing for reproducing software behaviour, yeah. I'd say NixOS's declarative config more/less covers the config files, where on non-NixOS you'd edit the files under /etc (and hope you didn't break anything). Whereas, Home Manager's declarative config is more/less the stuff underneath $HOME or the XDG config dir. Turns out that a few things with fish shell don't work with a purely declarative config. (e.g. the universal environment variables are stateful). For myself, I don't rely on writing all my configuration in Nix files. I configure fish shell using config.fish. (Though I do use HM to symlink the config file).
temptemptemp111 3y ago
[dead]
unshavedyak 3y ago
re: everything in Nix, i use normal configuration most of the time. Ie with Home Manager, i just have Nix copy (link) my config files to the place apps look for them. I only would even consider recreating them in Nix if i needed programmatic construction of them or if i was trying to distribute them as a Nix package or something. But for just me, and my own use - i see zero reason to recreate config files which are already managed by Nix. It's just extra work with no benefit as far as i can tell. Especially because i detest the Nix language. It also makes it very difficult to search for, because if you want to figure out how to configure X feature of Y app, you need to search for that and then mentally map it to Z Nix configuration which may or may not support it. It's just layers of needless abstraction for a single-use configuration.