homies VS nickel

This is awesome! I utilize `nix` on Linux and Mac but I haven't "drank the kool-aid" so I utilize `nix profile` and a makefile:

https://github.com/sontek/homies/blob/master/justfile

Fleek basically replaces my hacked together work flow with something that I'd actually utilize on a daily basis! Nix shouldn't be an all or nothing thing and this is one step closer to making it a generally available set of technology.

I see a lot of people mentioning home-manager / nix in the comments. I tried drinking the nix kool-aid and home-manager and all that was a little too much more me and landed on a hybrid approach:

https://github.com/sontek/homies

1. I use a `justfile` that calls `nix profile install ...` to install my packages, rather than using a nix configuration file. This allows me to use a standard package manager workflow rather than going "all in".

https://github.com/sontek/homies/blob/master/justfile#L24-L2...

2. I then use GNU Stow to install my dotfile configuration:

https://github.com/sontek/homies/blob/master/justfile#L93-L9...

I think this is a great middle ground where I can utilize `nix` as my package manager across Linux and Mac and have consistency while not having to learn the whole configuration language or change my workflow.

The other tools I use heavily in my environment:

- https://asdf-vm.com/: I find this better than installing python/node/etc from nix.

- https://github.com/casey/just: I use this as my command runner (similar to make but cleaner in my opinion)

Yeah, I think its things like this that make it hard to adopt nix. All I want is a way to say "I want jq, kubectl, and terraform installed" and have it available globally. Not for specific projects or anything like that.

Right now I maintain a makefile that installs everything for me using `nix profile`:

https://github.com/sontek/homies/blob/master/justfile#L14-L2...

Which almost exactly like I want. Only issue is sometimes a new hash is generated (which I don't understand.. maybe a config update in the repos?) and the makefile can't run anymore:

    error: packages '/nix/store/y65pp5hipid0fzxl1z7xjxdk4h9jwfw7-exa-0.10.1/bin/exa' and '/nix/store/gy0bqcs9mcan8af47wakdylhal67dpy4-exa-0.10.1/bin/exa' have the same priority 5; use 'nix-env --set-flag priority NUMBER INSTALLED_PKGNAME' to change the priority of one of the conflicting packages (0 being the highest priority)

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.