I’ve opened a PR with input from @dra27 and @avsm adding support for Nix depexts (system dependencies) to Opam.
Opam supports system dependencies for other platforms by invoking the system package manager, e.g. apt-get install .... However Nix is a bit different, as in general installing a package to your system doesn’t create the development environment required to use it; it will only add executables to your $PATH. To find, for example, objects files, outside of a Nix derivation you can use nix-shell and it’s descendant nix develop. E.g.:
$ nix-shell -p gmp
$ echo $NIX_LDFLAGS
-rpath /nix/store/20g5iw2r512gnfrdr4imp2y940v3vlif-shell/lib -L/nix/store/rx6nkd40819acppajq29g1hxa4d9r35f-gmp-with-cxx-6.3.0/lib -L/nix/store/rx6nkd40819acppajq29g1hxa4d9r35f-gmp-with-cxx-6.3.0/lib
We support Nix depexts with Opam in a similar way. A Nix derivation is build with the desired packages as inputs, and the resulting environment is output as a file in the Opam switch in a format that Opam can parse. This nix.env file is a symlink into the Nix store, so acts as a garbage collection root – packages won’t be removed from the store while this file exists. Opam outputs these environment variables on an invocation of opam env.
This fixes issues such as Opam and nixos: is there an alternative to nix-shell?.
While the primary use case is on NixOS, this depext mechanism could be used on other platforms to provide a consistent experience including other Linux distributions, BSDs, (and possibly even windows in the future).
Nixpkgs typically only packages one version of a package at a time, but I’m working on versioned depexts with previous version of Nixpkgs as outlined here.
I’m keen to get people’s opinions and perspective on this!