nix-direnv VS nickel

BTW: I personally use direnv with nix-direnv. This basically works by setting your shell with proper tooling when you enter the directory.

I'm not sure what you mean by nix env, maybe you are referring to nix-direnv?

Although currently I'm using direnv + nix-direnv. Keep in mind that direnv has builtin nix support which is very basic and doesn't do any caching. So you still needs this add-on to preserve roots.

I distinguish between system level things and user level things, even though I don't really have different users on my machine. I install the bare minimum number of packages + a lot of different drivers in the configuration.nix, and desktop and editor related things in HM. For development environment, I have environment per project using mkShell and https://github.com/nix-community/nix-direnv, which allows you to switch to the specific environment once you cd into the directory. (Although I do have python installed globally with some commonly used packages such as numpy, so I can just start python and write something when I need to, without creating an environment)

I further make my software projects so that when I click a link I go into an environment pre-loaded with their dependencies so dropping in/out of projects is always frictionless. I do this with the reproducibility guarantees of nix, along with glue like nix-direnv and envrc-mode to direnv.

(I also use nix-direnv)

direnv

Personally I use nix-direnv. No longer the need to run nix develop or nix-shell. By setting up a .envrc with either use nix or use flake it will automatically install all the packages from default/shell.nix or flake.nix

Direnv is installed using the nix-direnv installation instructions under "Via configuration.nix in NixOS". I read some recommendations that envrc.el is a better alternative then direnv.el, and after some testing I have to agree. (envrc-global-mode) is enabled in my config. This works perfectly with a normal emacs instance.

So, its key features are:

1. domain-specific: designed for conveniently creating and composing derivations. This reason alone already justifies a new language, or an embedded domain-specific language (such as the Guile/Scheme for guix), or a mix of both (Starlark, the build language of Bazel embedded in a restricted Python-variant).

2. purely functional: this ties well into the philosophical backing of Nix the package manager, which aims to be purely functional, also known as hermeticity in other build systems (Bazel).

3. lazily evaluated: similar to other build systems (including Bazel), so that you can build only what you need on demand.

4. dynamically typed: this one is controversial. Being dynamically typed—in other words, not developing a type system—gets Nix out of the door first. But users often complain about the lack of proper types and modularity. There are experiments to address this, such as Nickel (https://github.com/tweag/nickel).

It is understandable that a one-pager may not have space for the whys.

Nickel：Nickel is a straightforward configuration language aimed at automatically generating static configuration files. Essentially, it's akin to JSON with the addition of functions and types.

Also look at nickel which is an evolution of nix. It's my favorite in this space.

nickel-lang.org

https://github.com/tweag/nickel

Or this https://github.com/tweag/nickel

Nickel is a programming language. While HCL is just a configuration format, so not really comparable.

Here's a comparison with similar tools: https://github.com/tweag/nickel#comparison

As for 'providence', I suppose you meant provenance :) it's been delayed because this was less critical for 1.0 to decide on or to implement (as it: it doesn't break backward compatibility in any way to add this feature in the short term), but this is very much on the roadmap: Issue #235. That's a must-have in a language with merging like Nickel.

Have you considered using a different language for templating? this could be a BIG selling point. Some good ones are cue-lang (though I haven't seen support for rust), kcl or nickel-lang.