utdemir / nix-tree

Interactively browse dependency graphs of Nix derivations.
BSD 3-Clause "New" or "Revised" License
701 stars 11 forks source link

Feature request: graphviz export #59

Closed SomeoneSerge closed 8 months ago

SomeoneSerge commented 1 year ago

Hi! I don't know if nix-tree would be an appropriate place for this kind of a "generic" feature, but I think it'd be lovely to be able to do something like this:

❯ nix shell nixpkgs#nix-du nixpkgs#xdot
❯ nix-tree --derivation .#nixosConfigurations.$(hostname).config.system.build.toplevel --graphviz | xdot -i

...and nix-tree already provides the convenient interface of "installables" for the task of enumerating the full closure

Just to give an idea of what output I'm looking for, here's a screenshot for ```console ❯ nix-du -s=500MB | xdot - ``` ![image](https://github.com/utdemir/nix-tree/assets/9720532/b5fed45a-28a5-4d5e-b862-cb4c70b20634)
utdemir commented 1 year ago

Thanks for the issue! I agree, this is a useful feature.

If I understand correctly, the difference of your request and:

nix-store -q --graph /nix/store/na56nh4y1m0s1z5rgki99fj7imj433ld-nix-tree-0.3.1

is that, you can pass a flake reference, right?

If so, it does feel like it is more suitable to:

But on the other hand it really wouldn't be hard to add it to nix-tree, as we have all the dependency graph right there; we just need to print it. I gave it a go on ud/dot branch, can you check it out if it works for you?

nix run 'github:utdemir/nix-tree?ref=ud/dot' -- --derivation .#nixosConfigurations.$(hostname).config.system.build.toplevel --dot | xdot -i

Currently it prints out a simple dot file without any styling, formatting, and it doesn't look very pretty to be honest:

example

So, I am happy to merge it as-is, or let me know if you have any other suggestions to make it better :).

SomeoneSerge commented 8 months ago

Sorry about disappearing. Yes I think --dot and passing the "flake references" through is good. The graphviz format can be parsed by external tools (e.g. python's networkx), and doesn't seem to include any data other than what nix-tree already deals with. Wouldn't make sense to do more special-casing in nix-tree, and definitely not in the nix repo (nix path-info ... --dot doesn't sound unreasonable, but the nix cli is already overloaded).