💾 Archived View for dioskouroi.xyz › thread › 29421340 captured on 2021-12-03 at 14:04:38. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
TL;DR: Can we have an experience similar to `guix refresh` with content-addressed nix?
(Disclosure: experimenting with the content-addressed nix now, have not used guix before, but heard good things about it.)
It seems to me that there are some higher-level design decisions around usability that need to be worked out, concerning the push to content-addressed nix and making all build dependencies pure in restricted mode (to separate “fetching from external services with known hash” from “building without accessing external services”), particularly to interface with other language ecosystems (crate2nix of Rust, cabal2nix of Haskell, yarn2nix of Node, etc.), as summarized in this “Status of lang2nix approaches” discourse thread [1].
[1]:
https://discourse.nixos.org/t/status-of-lang2nix-approaches/...
I wonder what is the intended user flow for updating hashes of dependencies (say, from a certain language ecosystem).
Can we make it as easy as `guix refresh`, possibly with tools external to nix (similar to niv, lorri, and other nix-related tools which extend nix)?
Before the restricted mode in content-addressed nix, we could do, say, callCabal2nix which indirectly does import-from-derivation (IFD), that is, refer to an intermediate derivation which is computed. With the push to content-addressed nix, this appears to be ruled out (see the thread [1] for the alternatives, but it seems that there is no satisfactory approach yet).
If we want to make it easy to update dependencies with a single command (like `guix refresh`), what needs to be done? Do we need to change nix to accommodate, or we could do it with external tools alone (like the way niv and lorri which “patch” the nix workflow without modifying nix proper).