plugin-foreign-env VS nickel

I am not using Guix's Fish because right I just installed it and was hoping to kinda get my packages up to snuff for what I keep on my desktop. Though I was about to install foreign-env via omf and that seems to work! I am super new to Guix so I still gotta read up on Guix Home. I literally have only installed like 6 packages right now haha.

The official installer leverages an initialization script, to be sourced at shell init time, which is written in POSIX shell. Fish can't just source it because it's not compatible with POSIX shell.

> I then searched the Internet and found a very "creative" workaround for Arch users that didn't work either.

Arch users shouldn't need anything special here.

You can use fenv¹ to source it, you can translate it to bash using babelfish, or you can exec into fish after running bash to log in (make sure to set $SHELL after if you choose that option). Just make sure you do it as early as possible if you want to use things installed by Nix in your other Fish config snippets.

I think Home Manager will also take care of this for you. (The other module systems, Nix-Darwin and NixOS, both do.)

If you wanna do it like NixOS does, you can install Fish via Nix and then create your own preinit environment script in /etc/fish. This has the advantage of setting up your Nix environment variables before any other config is sourced. You can take a look at it here, which also explains some of the Fish initialization process: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/p...

and here's where the hooks go in the Fish package, where the comments describe the Fish initialization process in detail as well as why things are done this way on NixOS: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/p...

—

1: https://github.com/oh-my-fish/plugin-foreign-env

2: https://github.com/bouk/babelfish

That's just not true, most stuff already has a fish equivalent, and for the minority which doesn't there are plugins like foreign-env

I'm also interested in the correct way of doing this. Right now, I cheat by using the fenv plugin to source a bash ~/.profile file:

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.