[Nix-dev] "IO" in Nix

[Shea Levy]

Hey Dan,

This sounds a lot like the motivation and design for nix-exec, have you
looked into whether it might work for you as-is or with something built
on top of it? I'd be happy to chat about this too if you want to go over
in more detail.

~Shea

Daniel Peebles <pumpkingod at gmail.com> writes:

> Hi all,
>
> I've been experimenting with a pattern recently that I'd say is fairly
> close to a Haskell notion of IO. I have a collection of Nix-centered
> scripts that need to perform fairly restricted side effects:
>
>    - Build an AMI (image) for AWS
>    - Write some disk image stuff to a raw device
>    - Run some tests that talk to the outside world
>    - Build some stuff that depends in a fairly constrained way on mutable
>    external state (e.g., RPM update repos, as opposed to the deterministic
>    base repos)
>    - Deploy stuff
>
> These things all have the following in common:
>
>    - I build as much stuff possible in "pure" Nix
>    - I write out scripts (in the store) that all start with a
>    ${stdenv.shell} shebang and an explicit `export PATH` clause to avoid
>    inheriting an environment from the outside.
>    - The scripts rarely take arguments at runtime; instead I run them with
>    similarly to `sudo $(nix-build -A foobar)` or sometimes without `sudo`.
>
> I'm wondering if anyone else is doing something similar. It's basically
> (right now) analogous to a non-composable IO value in Haskell: pure code
> producing a "script" for some external impure interpreter to execute.
>
> I can think of a few next steps from here: start building composition
> operators (like bind) to chain together these impure actions without
> wanting to pull your hair out. I think Shea Levy's nix-exec already has a
> monad-flavored API for IO but I haven't seen anything like it outside of
> nix-exec.
>
> I'd also really like to teach Hydra how to (in restricted ways) run these
> IO values for me. I'd love it if my Hydra builds could produce a ton of
> pure work *and *upload an AMI to AWS. Then for example our nixos-unstable
> channel could bundle an AMI ID that's always up to date. I asked for a
> version of that feature in https://github.com/NixOS/hydra/issues/242 but I
> think this can be broader.
>
> Anyway, I was mostly wondering if anyone had feedback, ideas, suggestions.
> It seems like it might make sense to add a new top-level lib/ entry for
> producing these IO values without tearing one's hair out. I have a few
> ideas for combinators that make sense, and there are probably others I'm
> missing.
>
> Thanks,
> Dan