IIRC flake evaluation caching doesn’t work for nested package sets (as nixpkgs is) and thus is not disabled for anything that is in legacyPackages (normal packages has to be a flat attribute set).
On a more general note, I don’t think that plan for opam will be very fruitful – installing has a very different sense on NixOS to other linux distributions. Specifically depext for libraries won’t work, as NixOS doesn’t have something akin to /usr/lib where linkers will look for libraries, so not all depext will work as expected – or rather only depext that just want to make an executable available may work. (I seem to remember nixos depext where added as a way for opam2nix to track some needed metadata in the opam repository.)
Overall the use of nix-env has some pitfalls and there is a risk of messing up an users environment when invoking it in this way. If I were to add a Nix integration to opam, I’d rather have it set up a switch specific nix-shell environment and execute build commands within that environment (which of course would be a very different approach to other depext integration, but I believe necessarily so).
IIRC flake evaluation caching doesn’t work for nested package sets (as nixpkgs is) and thus is not disabled for anything that is in legacyPackages (normal packages has to be a flat attribute set).
It does seem like this is being cached, as the two flake commands are slow in the initial run and very fast in subsequent runs. Maybe this is because we’re only looking at the attr names. Do you know if this is documented anywhere?
On a more general note, I don’t think that plan for opam will be very fruitful – installing has a very different sense on NixOS to other linux distributions. Specifically depext for libraries won’t work, as NixOS doesn’t have something akin to /usr/lib where linkers will look for libraries, so not all depext will work as expected – or rather only depext that just want to make an executable available may work.
This is a very good point. My preference would be for creating a shell.nix (or flake.nix with a devShell) containing the depexts, as described here, which I believe should set appropriate flags for linking.
(I seem to remember nixos depext where added as a way for opam2nix to track some needed metadata in the opam repository.)
Interesting! I didn’t know this. I’ve had better luck with tweag/opam-nix for building OCaml projects in a nix derivation.
Overall the use of nix-env has some pitfalls and there is a risk of messing up an users environment when invoking it in this way. If I were to add a Nix integration to opam, I’d rather have it set up a switch specific nix-shell environment and execute build commands within that environment (which of course would be a very different approach to other depext integration, but I believe necessarily so).
Yes this makes sense, I think is the same conclusion we were coming to independently.
Previous art are the Nix integrations stack and cabal-install have. The latter one is a bit simplistic (just reusing a shell.nix manually written by the user), but they work similarly: build comands are invoked in a nix-shell.