Use Nix for reproducible environments?

will-ca commented 1 year ago

I got the below error trying to run the Zig version:

./build.zig:22:8: error: no member named 'addLibraryPath' in struct 'std.build.LibExeObjStep'
    exe.addLibraryPath("/Users/shish2k/homebrew/lib/");
       ^
./lib/sdl/Sdk.zig:139:63: error: expected type 'std.mem.Allocator', found 'std.zig.CrossTarget'
    const target = (std.zig.system.NativeTargetInfo.detect(exe.target) catch @panic("failed to detect native target info!")).target;
                                                              ^
/usr/lib/zig/std/mem/Allocator.zig:1:1: note: std.mem.Allocator declared here
//! The standard memory allocation interface.
^
/usr/lib/zig/std/zig/CrossTarget.zig:1:1: note: std.zig.CrossTarget declared here
//! Contains all the same data as `Target`, additionally introducing the concept of "the native target".
^
./lib/sdl/Sdk.zig:86:9: error: no member named 'source' in struct 'std.build.Pkg'
        .source = .{ .path = sdkPath("/src/wrapper/sdl.zig") },
        ^

Rather than endlessly trying to keep track of libraries, version incompatibilities, etc., I think Nix can be used to declaratively define reproducible, self-contained development environments as needed.

For example, I have the below shell.nix file for the Python version:

{ pkgs ? import <nixpkgs> {} } : pkgs.mkShell {
    buildInputs = with pkgs; [
        (python310.withPackages (pypkgs: with pypkgs; [
            pysdl2
            setuptools

            mypy
            black
        ])).out
    ];
}

(To read this if you haven't looked into Nix before: The language is functional. Colons are function definitions, with signature to the left and the return expression to the right. Calls are names followed by a space and then argument. With makes names from a mapping available in the subsequent scope. Lists are whitespace-separated, and curly braces are mappings. — The root expression is a function that takes the argument pkgs (or actually uses the default value import <nixpkgs> {}) and returns an environment, and the argument passed to .withPackages is a function that takes the argument pypkgs and returns a list of Python packages.)

And then, anyone on any distro of Linux or MacOS can just run $ nix-shell in the terminal to get the exact right development environment. The packages are stored entirely self-contained in /nix, and symlinked in ~/.nix-profile or added to $PATH as requested.

For perfect reproducibility, the packages used can be pinned to a specific version by downloading from a specific commit in the nixpkgs respository. So this way, if you specify a version of a library or language that works on your machine, anyone else running it will get the exact same version.

{ pkgs ? import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/facfd565093c8f410be840dc427975a6d7368f91.tar.gz") {} } : pkgs.mkShell {
    buildInputs = […];
}

More info:

https://nixos.org/guides/declarative-and-reproducible-developer-environments.html

I'm not trying to evangelize. I bring this up as somebody who is reluctant to modify my global computing environment for a local requirement— I.E. I'm not going to change my system Zig, set up venvs everywhere, or install new pip packages just to run this, so I was just thinking it'd be useful if a declarative ad-hoc environment were provided.

I do see there's already something similar with Docker/Podman, which I guess fills the same purpose. But that seems heavier (pulling in a whole Debian, looks like?), and involves more permissions and system configuration to set up. — FWIW, Nix can also be used to generate Docker images, and it looks like there's a Nix image on Docker (though I haven't tried either).

Anyway, it's just an idea.