4 ms·

> Most importantly, nix is incredibly invasive in development process, adopting it requires heavy time investments. Typically yes, but Nix actually allows you

> Most importantly, nix is incredibly invasive in development process, adopting it requires heavy time investments. Typically yes, but Nix actually allows you to be less pure to save time and pick your most economic point on the reproducibility continuum. I'm fairly sure there was an article about this... ah here it is: https://www.haskellforall.com/2022/08/incrementally-package-haskell-program.html https://www.haskellforall.com/2022/08/incrementally-package-...

vilunov 4y ago
This isn't what I was talking about, I'm all for being as pure as possible, dial the reproducibility and isolation to the max. Unfortunately, Nix itself as an application is not isolated. It requires a unique installation process to be available for users, because it wants to manage its store at the root level (/nix/store/), but I hear the situation is different on macOS. Applications packaged with Nix also require special treatment to run in Nix environment, with paths rewritten and binaries patched to support Nix filesystem structure instead of the traditional Linux one.
- ParetoOptimal 4y ago
  > It requires a unique installation process to be available for users, because it wants to manage its store at the root level (/nix/store/) Yes, for cache hits to happen it has to be this way as far as I remember. There is a project called nix-portable though that I've seen some HPC users report success with: https://github.com/DavHau/nix-portable https://github.com/DavHau/nix-portable > Applications packaged with Nix also require special treatment to run in Nix environment, with paths rewritten and binaries patched to support Nix filesystem structure instead of the traditional Linux one. If you fully package it. If you use something like an buildFHSUserEnv[0] that's not true. There is also nix-autobahn and nix-alien for automatically running foreign binaries on a more ad-hoc basis or to generate a starting point for packaging. 0: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environments https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...

vilunov 4y ago

This isn't what I was talking about, I'm all for being as pure as possible, dial the reproducibility and isolation to the max. Unfortunately, Nix itself as an application is not isolated. It requires a unique installation process to be available for users, because it wants to manage its store at the root level (/nix/store/), but I hear the situation is different on macOS. Applications packaged with Nix also require special treatment to run in Nix environment, with paths rewritten and binaries patched to support Nix filesystem structure instead of the traditional Linux one.

ParetoOptimal 4y ago
> It requires a unique installation process to be available for users, because it wants to manage its store at the root level (/nix/store/) Yes, for cache hits to happen it has to be this way as far as I remember. There is a project called nix-portable though that I've seen some HPC users report success with: https://github.com/DavHau/nix-portable https://github.com/DavHau/nix-portable > Applications packaged with Nix also require special treatment to run in Nix environment, with paths rewritten and binaries patched to support Nix filesystem structure instead of the traditional Linux one. If you fully package it. If you use something like an buildFHSUserEnv[0] that's not true. There is also nix-autobahn and nix-alien for automatically running foreign binaries on a more ad-hoc basis or to generate a starting point for packaging. 0: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environments https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...