5 ms·

I'm actually trying out Nix on a fresh Mac install since this week, but I'm not yet sure if I enjoy it. When things work it feels pretty great, documentation fe

by lycos 4y ago

I'm actually trying out Nix on a fresh Mac install since this week, but I'm not yet sure if I enjoy it. When things work it feels pretty great, documentation feels lacking though so when I want to do something I haven't done yet I generally try to find examples of something similar. I do think I'm beginning to understand the language better that reading the source nix files almost become the docs for me. The main problem I have is when I try to install a package that fails to install, usually it has to compile. Like today I tried watchexec on my M1, doesn't work. Luckily I can just download a binary watchexec build to get around it but it would be nice to know how to get it working. Worked with homebrew. (but homebrew has it's own problems) The other thing is that I like the idea of using nix-shell for projects, but I hoped they would be more isolated than they appear to be. It's possible for example to have files in a user directory which will be accessible to all projects and package versions I'm using. It hasn't become a problem yet in my testing so far though. Reading other comments I decided I will also play with running things in a VM with NixOS. Maybe I'll end up with a mix of local Nix for some basic stuff and then a development VM.

Kaze404 4y ago
Nix shell isn't supposed to provide file system isolation. It is a package manager after all, so what it does best is give a consistent dev environment with isolated dependencies. At that point if the program access mutable state and you want to prevent it (to a reasonable degree), you should use Docker or do it through the command line (like making $HOME point to somewhere else).
- lycos 4y ago
  Oh yeah are definitely right there, I honestly don't know where the expectation came from because it makes perfect sense that it doesn't do that. Why would it. I think it was more me saying "would've been nice.". I'm coming from homebrew + asdf, but so far Nix appears to be working fine for me. I think asdf has a lot of custom config to try and isolate version-specific shared files/modules etc. I can replicate it by setting some environment variables myself in nix shell file though. I've got my basic home manager setup (still need to migrate some manually managed files to nix config) and every project I work on is now running with their own shell.nix file. No huge problems yet, aside from the mentioned watchexec failing. Not yet sure if I'll keep it in my regular workflow, it's been an interesting experience and I would be happy to not need homebrew anymore. (Might just try ports too). I'm also curious to see how fast new versions of software will be added/supported, so I'll have to at least keep this running until that happens.
soraminazuki 4y ago
Nix is fundamentally a source-based package manager, so it'll try to build packages from source. However, since Nix packages are reproducible, it'll check the official binary cache first to see if it has already been built on Nix's infrastructure and download from there it's there. That's why Nix acts like a binary-based package manager most of the time. However, if a package fails to build or does build but isn't available on the binary cache yet, it would inevitably fall back to source builds. You'd occasionally run into this if you use the unstable channel of Nixpkgs. You can check https://status.nixos.org/ https://status.nixos.org/ to get a sense of how high the chances are of missing the binary cache. Basically the chances are high if the channel build is failing. While source builds aren't completely avoidable, you can alleviate much of the pain with a combination of declarative package management and dependency locking. It's what long term Nix users most likely end up using: * nix-darwin for managing system-wide configuration * Home Manager for managing user-level configuration * Nix Flakes for locking dependencies Once you have a working config, the same config would run anywhere, anytime. You can then use GitHub Actions to automatically update dependencies and check if they all build before merging. Also as a last resort, you can always revert to a previous config if something goes wrong.
ParetoOptimal 4y ago
> Luckily I can just download a binary watchexec build to get around it but it would be nice to know how to get it working. Using steam-run, nix-autobahn or using buildFHSUserEnv yourself.
- soraminazuki 4y ago
  Those solutions won't work on macOS, though.

by lycos 4y ago

Kaze404 4y ago

Nix shell isn't supposed to provide file system isolation. It is a package manager after all, so what it does best is give a consistent dev environment with isolated dependencies. At that point if the program access mutable state and you want to prevent it (to a reasonable degree), you should use Docker or do it through the command line (like making $HOME point to somewhere else).

lycos 4y ago
Oh yeah are definitely right there, I honestly don't know where the expectation came from because it makes perfect sense that it doesn't do that. Why would it. I think it was more me saying "would've been nice.". I'm coming from homebrew + asdf, but so far Nix appears to be working fine for me. I think asdf has a lot of custom config to try and isolate version-specific shared files/modules etc. I can replicate it by setting some environment variables myself in nix shell file though. I've got my basic home manager setup (still need to migrate some manually managed files to nix config) and every project I work on is now running with their own shell.nix file. No huge problems yet, aside from the mentioned watchexec failing. Not yet sure if I'll keep it in my regular workflow, it's been an interesting experience and I would be happy to not need homebrew anymore. (Might just try ports too). I'm also curious to see how fast new versions of software will be added/supported, so I'll have to at least keep this running until that happens.

soraminazuki 4y ago

Nix is fundamentally a source-based package manager, so it'll try to build packages from source. However, since Nix packages are reproducible, it'll check the official binary cache first to see if it has already been built on Nix's infrastructure and download from there it's there. That's why Nix acts like a binary-based package manager most of the time. However, if a package fails to build or does build but isn't available on the binary cache yet, it would inevitably fall back to source builds. You'd occasionally run into this if you use the unstable channel of Nixpkgs. You can check https://status.nixos.org/ https://status.nixos.org/ to get a sense of how high the chances are of missing the binary cache. Basically the chances are high if the channel build is failing. While source builds aren't completely avoidable, you can alleviate much of the pain with a combination of declarative package management and dependency locking. It's what long term Nix users most likely end up using: * nix-darwin for managing system-wide configuration * Home Manager for managing user-level configuration * Nix Flakes for locking dependencies Once you have a working config, the same config would run anywhere, anytime. You can then use GitHub Actions to automatically update dependencies and check if they all build before merging. Also as a last resort, you can always revert to a previous config if something goes wrong.

ParetoOptimal 4y ago

> Luckily I can just download a binary watchexec build to get around it but it would be nice to know how to get it working. Using steam-run, nix-autobahn or using buildFHSUserEnv yourself.

soraminazuki 4y ago
Those solutions won't work on macOS, though.