I’m wondering how feasible it would be to use the Nix evaluator without relying on the Nix store. I find this interesting because I find Nix to be a great configuration/templating language even without any of the “package management” features of the Nix tooling. As much as we love Nix, not every project or team is able to embrace Nix completely, or some projects can do it, but not all stakeholders are willing (or even able) to go all-in with Nix. For such circumstances, it would be great to have Nix the language + the Nix module system available as an easy to distribute evaluator, like a statically compiled binary + a bunch of .nix files so that pure configurations can be evaluated in environments where a full Nix installation is not possible/desired, like, say Windows, a microcontroller, the browser or a Nix-averse peer’s computer.
Does anyone know of a project in this direction? I know that one could always use alternatives for this purpose, like Dhall, Lua etc. But I frankly prefer Nix + the module system as a configuration medium above all else.
You might be able to build a minimal evaluator using the experimental C bindings and a dummy store. Of course builtins.toFile wont work, and none of fetchers either. Those aren’t avoidable if you want to import arbitrary code.
@shanesveller You’re right, there is quite a selection of languages tailored for configuration and I think Nix is a very nice choice among them. Here I’m specifically interested in (a subset of) Nix tailored to that use case without the burden of having to make the host system significant changes. I’m specifically interested in a Nix subset, because that would be very useful for a team/project that already has a lot of Nix components, but would also like to have some parts that can be interacted with without having to install Nix, while retaining the ability to import them directly into the rest of the Nix setup.
That said, it seems like Nickel has some Nix interpretation capabilities, but I don’t know if Nickel itself is designed to work without a /nix/store. I’ll look into to it.
@ehmry Thank you for the pointer, this is indeed a promising approach. As you’ve noted, taking this route might be overly restrictive about remote dependencies; An ambitious enough project should be able to deal with, say, flake inputs and flake.lock without needing a /nix/store, am I wrong? I guess this route could also make it more challenging to compile it for Windows and WASM etc.
Otherwise there is also nix-portable but I believe it would work only on Linux (when using bubblewrap at least, don’t know about proot). Probably it would work in WSL.
Notice that it creates a store in your home tricking nix into thinking that it’s the real system one.