Depending on non-OCaml languages from the opam repository

Ecosystem
6

Nix is really good for multi-lingual projects. I’ve created a proof of concept for opam to use Nix to provide non-OCaml dependencies: github.com/RyanGibb/opam-lang-repo-nix.
You can add it to opam with opam repo add opam-lang-repo-nix git+https://github.com/RyanGibb/opam-lang-repo-nix.git and add a dependency to your opam file as, e.g. nix-rustc.

The opam files looks something like:

opam-version: "2.0"
synopsis: "Rust"
install: [
  "nix-env"
  "-iA"
  "rustc"
  "-f"
  "https://github.com/NixOS/nixpkgs/archive/28e0126876d688cf5fd15da1c73fbaba256574f0.tar.gz"
]

Nix doesn’t, in general, package all the versions of a package (github.com/NixOS/nixpkgs/issues/9682). You can install a previous version by using a specific git revision of Nixpkgs. I’ve cherry-picked some git revisions using lazamar.co.uk/nix-versions/ to get an MVP working for the rust compiler and python interpreter. This is where the 28e0126876d688cf5fd15da1c73fbaba256574f0 you see above is from.

Some advantages:

  1. Reproducible and deterministic dependencies. I don’t know a lot about devcontainers, so please correct me if I’m wrong, but it looks like they just run a large number of large ‘install’ bash scripts. I can imagine the user loosing track of the side-effects of these scripts, and the exact versions of the dependencies they pull in, and not being able to easily reproduce their development environment.
  2. Benefit from the huge number of packages in Nixpkgs.
  3. Allows multiple versions of a package to coexist on the same system without any interference. If the devcontainer install scripts are sandboxed/containerized (again I’m hazy on the details), then another advantage of Nix is it allows transparent sharing of identical dependencies.
  4. Atomic upgrades and rollbacks, which again come for for free with Nix.

Some issues:

  1. This requires nix to be installed. We could have opam install nix as well.
  2. It similarly requires sandboxing to be disabled. We could pull in the Nixpkgs revision in advance but Nix will still have to pull in the sources for the derivation closure it’s building.
  3. This uses nix-env to install dependencies to the local user’s profile. While this is less side-effectful than install scripts, as dependencies are still constrained to the Nix store, it would be more desirable to create a shell in which these dependencies are available. Nix flake devShells could be useful.
  4. Similar to:
  • We would want a way to keep this repository up-to-date with upstream Nixpkgs. The project I linked to, github.com/lazamar/nix-package-versions, is already doing something very similar in keeping their website up-to-date.

A potential solution to issues 1, 2, and 3, would be for opam to generate a flake.nix file that contains all the dependencies. If we wanted to take this even further, opam could also generate nix derivations for packages from opam-repository. This could be through of as the inverse approach to something like github.com/tweag/opam-nix.

3 Likes