Thank you @Anderssorby !

Could you clarify what you mean by "what an output directory contains and what an input source directory contains"?

Would be nice to also be able to nix show-derivation ... for a .drv under the cursor.

I didn't know about this command, thanks! I'm always happy to add more pieces of information to the UI, however show-derivation has a pretty lengthy output, so I don't know how best to render it; just dumping the JSON does not seem very useful. Is there a specific information you'd like to use from that command?

@utdemir So I guess just presenting a modal of nix show-derivation possibly with some json formating and tree collapsing.

So the drv specifies outputs and inputSrcs both of these are folders which contains files that is very interesting to explore. If it was possible to print out and navigate a tree of this (in a modal) it would be super useful. Also the ability to read text files and execute commands like nm libmylib.so | grep ... would be really useful.

Thanks @Anderssorby, I think I understand it a bit more now.

To be honest, these look hard:

a modal of nix show-derivation possibly with some json formating and tree collapsing.

Also the ability to read text files and execute commands like nm libmylib.so | grep ... would be really useful.

So, your issue suggests me more like it might be better to make nix-tree a bit more shell-friendly. I will have a think about it, but briefly what I can think is that:

• Add a shortcut to nixpkgs that spins up a shell, with the selected store path as cwd.
• Add a shortcut which lets running an arbitrary command and showing its output, passing the current path as a parameter. ie. you can pass nix show-derivation {} for what you just asked, or it might also help with things like Feature request: Manage gcroots interactively #23, where one can pass nix-store --delete {} to delete a store path. There, maybe we can have a set of predefined commands for common use cases like yours.

Would this work for you? Can you think of other approaches where we can make nix-tree work for use cases like yours without introducing too many functionality?

That sounds nice. I wouldn't need much more initially and that is essentially what I've been doing manually.

I'm also working on this https://github.com/Anderssorby/Nix.lean evaluator and parser for nix in Lean (like hnix) which I'm hoping can be useful for things like this.