meta: initial work on Hjem Standalone

[NotAShelf]

I still haven't decided whether I want to do this in one go or in phases to build confidence as we go. As it stands, this PR provides the initial draft of the Hjem CLI I'm envisioning. As discussed on Matrix the CLI currently provides three invocation methods (hjem, hjem internal and hjem standalone) and acts as a replacement for pkgs.smfh, leveraging its library component after my latest refactor.

The CLI replaces a fair bit of NixOS and Darwin logic (primarily the Bash parts) and provides the necessary primitives for standalone, which (for the time being) include hjem standalone init, hjem standalone build, hjem standalone switch and a few other goodies (see --help). The CLI is not final, because I have not yet decided whether I like the subcommand approach. A much better way of doing this could be to allow symlinking the hjem binary as hjem-standalone and hjem-internal to make them do what their subcommands do and only that, i.e., don't leak hjem internal into pkgs.hjem when a standalone user only needs the standalone features. The names and design choices are all WIP, and feedback is welcome.

TODO

• Cleanup NixOS module
• Cleanup Darwin module
• Update top-level.nix
  • Update linker option to default to hjem
• VM Tests
• Documentation
  • README
  • Manual

[NotAShelf]

Ready for testing!

[Gerg-L]

Workflow failure

May 30 21:51:57 node1 hjem-activate_-start[1294]: failed to copy '/nix/store/8ja5hly930fzyz75vkwl124fk9v7dhsm-hjem-manifests/manifest-alice.json' to '/var/lib/hjem/.hjem-manifest-1294.tmp': Permission denied (os error 13)

Damn permission issues

[eclairevoyant]

Standalone can't use /var/lib, it'd have to be its own state directory.
Like ~/.local/state or something.

[Gerg-L]

The only thing i see missing from the hjem cli is a uninstall command, which would be implemented by running smfh's deactivate on the most recent manifest, and then running the already implemented command CleanupState

however i don't think this is absolutely necessary to merge this

[Gerg-L]

Suggested change

	(pkgs.callPackage ../cli/package.nix {})
	(pkgs.callPackage ../../cli/package.nix {})

[NotAShelf]

Good catch ty. I should get rid of backwards imports altogether...

[eclairevoyant]

Unfortunately if you don't use relative imports, you get rebuilds every time the flake changes. It's annoying, but this is the better option in most contexts.

[Gerg-L]

@eclairevoyant https://github.com/Gerg-L/norebuild build both commits, no rebuild