Update repl.nix implementation

[gytis-ivaskevicius]

Changes required:

• Make nixosConfigurations optional
• Turn it into a tiny overlay that is added by default. Maybe package name should be fup-repl, exec name repl? Any thoughts?
• CLI behavior:
  1. $ repl - opens pretty much existing repl
  2. $ repl /path/to/flake.nix - opens repl with specified flake loaded (I am really missing this feature :D )

More or less fixes https://github.com/divnix/digga/issues/17

[blaggacao]

Turn it into a tiny overlay that is added by default. Maybe package name should be fup-repl, exec name repl? Any thoughts?

I'm still trying to find a good reason for why it's not best option to keep it as a lib.

I think there are two broader use cases:

• Play the flake
• Play a specific host

For "play the flake", self.pkgs is probably fine to discover available packages.

For "play the host", I have no clear picture of what a user would want to do host-specific that only can be something with that particular config, right? I'm still repl-blind. Although, then self.nixosConfigurations would satisfy that need?

[gytis-ivaskevicius]

I don't think I quite get your point. Mind elaborating on "play the host"? In case you are wondering why is it host aware - the explanation is simple: It is convenient to have a system config (parsed options) exported to inspect :)

[blaggacao]

In case you are wondering why is it host aware - the explanation is simple: It is convenient to have a system config (parsed options) exported to inspect :)

That was it! :+1:

Would it make sense to provide a configs that holds all parsed config per host or something?

So to remain host aware, but make the repl itself only flake specific.

[hazelweakly]

For reference, I borrowed heavily from this repo's repl.nix when designing one for a non nixos config project

let
  flake = builtins.getFlake (builtins.toString ../.);
  nixpkgs = flake.outputs.legacyPackages."${builtins.currentSystem}";
in {
  inherit flake;
} // flake // builtins // (builtins.removeAttrs nixpkgs [ "config" ])
// nixpkgs.lib

Essentially the difference is that it references the flake by path instead of self and doesn't overlay flake.nixosConfigurations. It's been quite helpful. I use it as nix run .#repl for this project where the app is shell script that runs the command nix repl "$(git rev-parse --show-toplevel)"/nix/repl.nix, but adding that shell script as a package is another alternative I suppose.

[gytis-ivaskevicius]

@blaggacao I guess the other option would be to just do // flake.nixosConfigurations this way you'd access the config via <hostname>.config. Tho, I'd really rather stick with just config, it's just less bothersome.

@jared-w This implementation is quite slow, not only often wait to evaluate/build the repl app but also more often than not flake evaluation itself is not going to be cached :/ So yeah, you might want to tweak it a little.

The idea of using self is that it just grabs the last successful build of your config. And I believe that $ repl /path/to/flake.nix pretty much resolves your use case as well! :)

[gytis-ivaskevicius]

Oh, right @blaggacao - from my example above I did mean that in case the path is defined - repl is going to be flake specific as you just now. Otherwise it just assumes system flake

[gytis-ivaskevicius]

Some work was done on this. What still needs to be implemented:

• Expose the overlay externally
• Make self flake in registry optional. Probably expression like this is needed (head ( filter (it: it.from.id == "self") (fromJSON (readFile /etc/nix/registry.json)).flakes )).to.path
• Add --help
• Possibly avoid nixpkgs https://github.com/gytis-ivaskevicius/flake-utils-plus/blob/various-fixes/lib/repl.nix#L11 due to it being slow on non-cached flakes?