Have an ex-post discussion about the design of this

[blaggacao]

Maybe the contracts required from sub-commands to "blend in" is not the best idea we could have come up, so have that discussion here.

[nrdxp]

I'd like to see a rewrite of this utility in a better language than bash before it gets too much farther. Rust would be particularly useful since we could make use of rnix-parser to get information about the flake (I've had some crazy ideas in my head regarding a nixless bootstrap 😅 ).

In addition, I'm considering drafting a proposal to the Nix cli for an official extension mechanism of some kind, perhaps similar to gits, so if that does eventually take shape, we'll want to be ready for it.

[blaggacao]

I like the idea of using a better language than bash

Rust would be particularly

In order to remain composable (after all that's the idea behind using the module system), some scripted language would be imperative.

The main selling point using the module system here is that people can quickly compose their own system ctl tool.

[nrdxp]

I dunno if it's so important than people be able to modify this script though is it? What would be an example use case for that? Keep in mind, I may not yet fully understand the direction you are pushing here, since I'm still imagining a simple replacement for my simple bash script.

[blaggacao]

Over the past refactorings flk has been pushed down (not as a result of a very conscientcious choice) into the digga lib, was actually broken (no tests) and had quite some layer violations (e.g. get depends on devos branch naming).

On the other hand, I realize the genuine value of a flk command, especially after #1. That should enable us to access a common system manipulation frontend from anywhere, be it a devshell, or the actual system running.

The self flake should thereby have a special reference and together with hostname procure so that all commands (that make that distinction) can default to something that would be the current configuration of the current context.

So with that in mind and a modular and composable command aggregation system like the proposed one in place, we can:

• move the get command to devos
• let users configure and customize their system entrypoint (flk)
• wrap in nvfetcher and agenix to lift them out of the devshell (since they are useful outside of it, again with a special reference to the current config)

Making this composable should also help us a bit to do the spring cleaning which in my opinion is in order, before we update the docs next time.

---

As for the language of choice, I'd favor something loosely coupled and very scriptable.

I'm not convinced that bash is the best choice: I've spent roughly 3-4 hours debugging some bashism that have fallen behind in my main memory.

On the other hand, enforcing any scripting language probably neither is the experience users would expect to quickly hack their system ctl command.

Maybe we can provide a set of "trivial builders" (besides bash, perl and C) that can be used to quickly hack together subcommands in a variety of languages.

---

I also realize that we are getting (fortunately not dangerously) close to a possible nix plugin system a la git.

I see the main distinction in that flk can have a special reference to the current configuration and do work upon it. That also means it needs probably write and commit access to the repo that holds this configuration.

Whereas a nix plugin system is a way to expand the nix command and to factorize its development (and maybe unstuck flakes), flk can be the thing that users can customize to do any work on their systems or system state.

[blaggacao]

c6d3ee9 , specifically the use of exec allows to execute arbitrary shebang scripts written in any interpreted language.

This change also pulls the exotic declaration of script metadata out of the script itself.

This change also prepares for #2.