Haha, fair enough. The reason I even created this in the first place was because of how painful nix/nixOS is to use in general. Nushell is far simpler, and much more ergonomic to deal with. Especially with how much it supports structured data.

Ah yes, I came across this when someone else pointed it out as well. The project looks neat, ngl. supac also shares some goals along these lines, but dcli looks more mature. I still prefer supac (it's my project duh) because supac allows you to script in nushell, which lets you do interactive development (if you use nushell as your shell, which you absolutely should!). I also don't prefer something like YAML for config, but since it's extensible with lua, I guess it makes sense to go with a config language as well. I do think the end goals are different, I try to orient supac to be a nix alternative but with integrated package management across different package managers. Also, supac is simpler in principle because a lot of the complexity is shifted to accompanying libs in nushell (such as systemd unit integration).

Not to mention, with a couple of lines of nushell code you can probably import all your yaml configs from dcli into supac :)

From what I understand (I've never used mise), mise is meant for programming environments and tools. Supac works with your distribution's package manager to manage all your system packages and also language toolchains like rustup and uvx (uvx backend doesn't manage toolchains yet, it's being developed though).

What it doesn't manage are programming environments, basically, you cannot use it to spawn something like a nix devshell. Hope it makes sense. This is more meant to be along the lines of something like nix, but friendlier and easier.

Dcli looks interesting! The long term goal of supac is to support many different relevant package managers as backends, so that all sorts of packages and language toolchains can be managed. Besides, nushell being a scripting AND shell language massively helps with that.

Thanks for the kind words! For dotfiles, I used org-babel for a long time, keeping a literate config. Now I use a git repo to hold everything with a script to pull in whatever I think is necessary. That said, one of the long term plans for supac is to add dotfile management as well, something like nix-wrapper does it. Although it will certainly take some time before we get there.

Right now, you can do it in two ways:

• Don't have the Arch key at all. supac will silently skip it.
• You can write a small wrapper in package.nu that checks the presence of your preferred arch package manager in $env.PATH, if it's there then it'll insert the key and value, and not otherwise.

I'd mostly go with 1 unless you're sharing your non-arch config with an arch config on two separate machines.