Opening up dev-env: "Nix with training wheels"

News
1

Hi all :wave: ,

I think this is my first non-reply post :thinking:

We’ve just released dev-env, a tool we use internally, as an open-source repository.

We use it on many projects internally, and it’s actually already part of the Daml Connect repository, but there was no easy way for anyone else to use it before now.

So what is it? From the README:

dev-env is a set of tools that let you:

  • pin the exact version of the executables used in building your project, and
  • transparently manage those executables so they do not interfere with anything else on your machine.

If that sounds at all interesting, head over to the project page for more information.

9 Likes
2

Should be called nixenv in analogy to pipenv. Shame nix-env is already “taken”.

2 Likes
7

Thanks, it’s nice to see a simple way of setting things up that’s been ironed out over a few different projects.

By the way, are there any plans to release the Daml SDK itself as a Nix package?

8

For what it’s worth, we’ve actually stopped using dev-env for new projects internally, and just use nix-shell directly. You can see an example setup here, though that’s one of the more complex ones.

I’ve made this little script locally to help me initialize new projects:

#!/usr/bin/env bash

set -euo pipefail

if [ -f .envrc ] || [ -f shell.nix ] | [ -f .envrc.private ] || [ -d nix ]; then
  echo "Conflict detected. Not proceeding."
  exit 1
fi

cat <<EOF > .envrc
use nix

source_env_if_exists .envrc.private
EOF

cat <<EOF > shell.nix
# Update nixpkgs with:
# nix-shell -p niv --run "niv update"

let
  sources = import ./nix/sources.nix;
  pkgs = import sources.nixpkgs {};
in
pkgs.mkShell {
  buildInputs = [
    pkgs.bash
  ];
}
EOF

cat <<EOF > .envrc.private
# export MY_VAR="some value"
EOF

nix-shell -p niv --run "niv init -b nixpkgs-unstable"

I’ve written up some thoughts on the subject a few months ago in my personal, not-endorsed-by-DA-at-all blog.

Not as far as I’m aware, no.

1 Like