Dump configuration target

[xdbr]

Would it be possible to add some facility to dump the generated configuration after everything is tangled up and wired together? I'm thinking about a nix run .#dump-configuration target or something similar (maybe something like nix-topology could serve as an inspiration?).

I think this could help new users, particularly in these early stages of development to be able to directly inspect the generated outcome of their actions and be able to debug a little easier?

[vic]

Hey, @xdbr. I'd say that everything is possible unless proven otherwise. I also like the idea of exploring generating diagrams, since flake-aspects form both a tree and a dependency graph, it would be nice to have a way to visualize it.

Having said that, I don't believe it is currently on my roadmap -I'm trying hard for Den to be stable enough to move on into social aspects in denful-, but it can be part of yours, feel free to explore the idea, I'd be glad to help if you are willing to put some code into the idea. But I'm sure this will come very valuable as more people try to understand their own configurations and available aspects.

So, here are some ideas (nothing proven, just what is on top of my mind right now), feel free to explore, this could be a cool project on itself.

Target configuration is available on each Host/Home via their .mainModule, for example:

{ config, ... }:
{
  perSystem = { pkgs, ... }: 
   { 
     packages.dumpConfiguration = pkgs.writeShellApplication 
     let
       hostConfig = config.den.hosts.x86_64-linux.my-laptop.mainModule;
       graph = # TODO: traverse hostConfig and generate a visualization of it.
     in
     {
       name = "dumpConfiguration";
       text = ''
         somehow dump the graph here, use graphviz or anything you are exploring.
       '';
     };
   }
}

Something like that, mainModule returns the darwin or nixos module for the Host, be aware that it will internally have a lot of imports hops, because all that flake-aspects does when resolving the modules is generating imports for their dependencies. So it is not about just visualizing the modules as they are, we'd also need that visualization to be concise and meaningful for humans.

From the name of your app, I believe this is what you are targetting, generating a visualization of the generated configuration. I'd personally be more interested in visualizing the aspect trees themselves (my interest is in having people know what tools are available to them). But again, I see value on both goals.

First steps I'd recommend is, use nix repl .

{ config, ... }:
{
  flake.myHostModule = config.den.hosts.x86_64-linux.my-laptop.mainModule;
}

and try exploring that myHostModule from the repl or see if you can use code/facilities from nix-topology to "dump" that host module easily, perhaps you don't have to do much. Explore :).

The only limitation to "dumping" would be functions, they are not serializable, and anything behind a function would need first to call the function for you to visualize the result. And Den uses a LOT of functions, aspects are functions to plain configurations, so there's something to be aware of.

Yours is a very good idea, thanks for sharing it.

[xdbr]

Hey @vic, I'm sorry if the example of nix-topology was misleading – I didn't mean a visualisation per se, but rather dumping the resulting configuration.nix for inspection. Dumping the actual graph dependencies between aspects, etc is a whole different, albeit beautiful idea in itself!

For debugging purposes, I have already started to explore nix repl, and this is how I actually came to this idea of dumping the resulting configuration. Thanks for mentioning mainModule – I will explore along this path and see how far this can get me.

In case dumping the resulting configuration instead of a visualisation is not at too far a distance, maybe it can still be useful?

Thanks for all your efforts and your quick and detailed responses! :)

[vic]

Links that might be related to dumping configs: 1, 2

[vic]

Looks like "dumping" an arbitrary configuration might not yet be possible. due to having to evaluate everything to render it (and nix is lazy), and possibly hitting infinite-recursion points.

[xdbr]

Ah that makes sense, your're right, I completely forgot about the lazy evaluation!

[xdbr]

As a heads-up, I just found https://github.com/bluskript/nix-inspect which can be useful to inspect the resulting configuration at outputs.nixosConfigurations!

[vic]

You can if you bind an aspect as flake output:

{ den, ... }
{
  flake.inspectMe = den.aspects.my-laptop.modules.nixos;
}

then launch nix-inspect or the repl to browse the inspectMe output.

[xdbr]

I call it flake.inspector ;)

I'm sifiting through using nix repl as nix-inspector only gives me function as the value

Fantastic stuff!

[vic]

I have an idea, but...

I have an experimental Nix language parser last time I checked it was able to parse all nixpkgs, except for a couple of files. And we could have an interpreter that never materialized derivations.

I need to get patrons to be able to dedicate more time this kind of Nix stuff. Months ago I wanted to create a Nix compiler (not an interpreter), but real life (and paychecks) get in the way. :D

Anyways, I was thinking about creating a web service (much similar to my nix-versions) where you paste the URL of a flake and it allows you to browse the flake on the web, evaluating as much as it can (but not doing derivations). I will be thinking more about something like that.

I know it is possible to disable local-builders in nix, so derivations are not built using the current Nix impls, but that would just fail the complete evaluation. I need the evaluation to do as much as possible just without derivations.

[xdbr]

In case dumping the resulting configuration instead of a visualisation is not at too far a distance, maybe it can still be useful?

Exactly this was my initial concern that this would be wayyy to much work to set up!

So nevermind and thanks for investigating!

If fact, the current nix-inspect together with nix repl is already enough for 98,5% of the cases ;)

I just wanted to throw it out there as an inspirational idea, in case this was a low-hanging fruit – let's consider this case as closed :)

[vic]

If fact, the current nix-inspect together with nix repl is already enough for 98,5% of the cases ;)

Awesome! case closed, then :)