devenv_new – Mix task wrapper to create projects in a new devenv.sh Nix environment

Super cool! I will try it out later.

One question, did you also setup the variable envs so all created files are encapsuled inside the project directory? For example, in my devenv config, I setup it so all postgres data will live inside the project directory (I think inside .env/.devenv/state/postgres), I also made that all elixir config files like hex, mix, erlang-history, etc are all inside the .env/.devenv/state too.

In other words, running elixir, postgres, erlang, etc never leaks anything outside the scope of the project.

No special env setup, so far. PostgreSQL lives under .devenv/state/postgres by default. All state is contained within the project folder, but not necessarily under .devenv.

If you have a good env setup to share, let me know. So far it only knows about languages and services, but other classes could be added.

For Elixir, I define these variables:

  state_dir = config.env.DEVENV_STATE;

  mix_dir = "${state_dir}/mix";
  hex_dir = "${state_dir}/hex";

And then I set them like this:

    env.ERL_AFLAGS = "-kernel shell_history enabled -kernel shell_history_path '\"${state_dir}/erlang-history\"'";

    tasks."elixir:setup" = {
      exec = ''
        mkdir -p ${mix_dir}
        mkdir -p ${hex_dir}

        export PATH=${mix_dir}/bin:$PATH
        export PATH=${mix_dir}/escripts:$PATH
        export PATH=${hex_dir}/bin:$PATH
      '';
    };

    env.MIX_HOME = mix_dir;
    env.HEX_HOME = hex_dir;

    env.ERL_LIBS = "${hex_dir}/lib/erlang/lib";

For postgres I set this:

    env.PSQL_HISTORY = "${state_dir}/psql_history";

For node, these ones:

    env.NPM_CONFIG_CACHE = "${state_dir}/npm";
    env.NODE_REPL_HISTORY = "${state_dir}/node_repl_history";

And, if you plan to add support for rust, I set this:

    env.CARGO_HOME = "${state_dir}/cargo";

Thank you for the inspiration! I was considering isolating Hex archives, actually.

This is pretty neat! I’ve been planning on getting into nix & devenv at some point, especially considering how important it is getting to be able to run containerized local development. Its on my short list to checkout

Why would you want nix to run containerized stuff?

(Genuine question, the benefits seem overlapping)

It allows you to have full development dependencies per project and scoped only for them. It gives you access to basically all packages from Nix so you can setup it the way you want and do that in a declarative and consistent way.

IMO it is the best way to setup you development infrastructure without having to handle that at the OS level, specially if you work with multiple projects with different dependencies.

The only downside, IMO is that the nix language is kinda hard to work with if you don’t want to spend a lot of time understanding it.

PS. i’m talking here about using devenv, NixOS and Home Manager are not required to work with devenv at all (but I do like them a lot too)

I know what nix does, what is confusing to me is how zach is going to get benefit from nix AND containers at the same time. Unless he meant «comtainerized» abstractly achieved via nix and not oci combined with nix

Sorry, I kind of conflated a lot of things in one post, but my real point is that there are a whole host of tools, like nix and devenv, that I’ve been meaning to look into, specifically for agentic workflows (which may involve containerization, repeatable builds, sandboxing etc. TBD).

Container from “to contain”, Docker, LXC etc. offer containers, Devenv achieves “containerisation” in a different way, without strict file system boundaries.

That being said, Nix in general has good support for bundling a config in an OCI container, see here for Devenv.

Devenv is a good way to get a feeling for Nix: You can treat your devenv.nix as a config data file without knowing the Nix language, some of the more complicated stuff can be setup via devenv.yaml, like adding additional package sources.

Without Devenv you would typically create a Flake providing a dev shell – for me that typically meant looking for and starting with a template. Always felt a bit cumbersome when I just required an ad-hoc environment to play around with some piece of software written in obscure language xy…