nickel VS nix-index

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.

nix-index can be used to provide this functionality, and to automate this process you can use nix-index-database (setup instructions are in the README).

Are you using flakes? AFAIK `command-not-found` does not work with them. See https://github.com/NixOS/nixpkgs/issues/171054 and https://discourse.nixos.org/t/why-isnt-there-an-official-bui...

I think `nix-index` works as a replacement: https://github.com/bennofs/nix-index

If you are on another distro or mac os there is also nix-index

nix-index is another option for searching for pkgs. You can search by name, or by specific files within a pkg.

You can use nix-locate from https://github.com/bennofs/nix-index to find files on NixOS:

nix-index makes it trivial to find which package contains a given file.

There are two ways I know of: - If you use old-school channels, there's an index in the channel. In particular, the command-not-found hook is able to use that. In this particular case, you would have to guess that git will look for the git-clang-tools, and command-not-found that. This looks like it only works for programs, not arbitrary files. - In any case, you can use the more general nix-index. That's what I did because I use flakes.

I use nix-index a lot to find which derivation a file belongs to, but building the index takes a while and so I end up not updating it very frequently.

Look at the library missing say X Use nix-locate to find the derivation that includes libX.dylib file (if it can’t find the macOS dylib version of the file try using the same name for linux by changing dylib for so) Add the derivation to you environmental and try again It will find the next missing library on the next compile.