Reverse dependencies (--query --referrers)

[dschrempf]

Hi!

Thank you for developing this tool!

I was wondering if it is feasible to include a way to inspect reverse dependencies? Specifially, I was thinking about a way to add information obtained from nix-store --query --referrers. I need this command quite often, and it is very long (and hard to remember).

Thanks for you input!

Dominik

[utdemir]

Interesting thought, and I can see how this is useful.

However, there's a conceptual issue that I've been thinking about for a while; since there is a vaguely similar issue, #15. The reason I'm finding this hard to think about is that it changes the way how the nix-tree panes behave.

nix-tree is currently only for delving "down" into the dependencies. The asymmetry is that, the right pane shows all the dependencies of the selected store path, however the left pane does now show all the paths that depend on the store path, it merely an indicator of how we navigated to that point. Another explanation of this is here.

Initially I was imaging how this feature would work is that it would start with the passed path, going towards the right pane would take it to that paths dependencies, but going to the left pane would navigate through the passed paths parents. But this actually does not work, because once you move left from the selected path, the meaning of the panes change.

So, the second option would be to have a "flipped" version of nix-tree, where it starts with the selected path in the middle, right pane is empty, and the left pane contains all paths that depend on the selected path.

This is already hard to think about (even for me as the tool author). And it doesn't solve all the issues, since it is kind of like the "why-depends" functionality, but not quite; also it is kind of like #15 , but also not quite. I feel like there's a nice design somewhere, but I am failing to grasp it.

I'd be happy to discuss this more, so it would really help if you (or maybe @wmertens) could explain what you're thinking about how this functionality would work a bit more (eg. how would you invoke this, is it a command line flag or a shortcut when navigating nix-tree, or even extending the default view, how would you navigate through them).

[utdemir]

I need this command quite often

Just as a data point, could you also tell how is it useful? I can not remember when I had to do a query over the entire /nix/store, since in my mental model what you have in /nix/store other than what's reachable from your gcroots does not mean much, it's just a cache.

One useful query I'm thinking of would be something like "why isn't this path garbage collected", or "why do I have that path on my system", and for these questions issue #23 (with the existing search and why-depends functionalities) can be a more to-the-point solution.

[dschrempf]

Thanks for your detailed answer!

I was having a look at your references, and I think I get the point. I rephrase:

The left-most pane contains the elements that have been viewed in the middle pane before moving down a branch on the tree.

I was not completely aware about this design desicion of nix-tree. At this point, I only can think of a shortcut that gets all reverse dependencies of the focused element in the middle pane (i.e., that runs nix-store --query --referrers), and then fills the left pane with those results.

In other words, a shortcut that displays all direct reverse dependencies of the focussed element in the left pane.

Does this make sense?

Use cases are manyfold. One that comes to my mind right now: I perform a system update. I see that package x gets updated. I am like: "Why do I have package x installed?" So I walk up the dependency tree and see, ah, package importantPackage depends on x, so that's why...

[utdemir]

Quick question:

In other words, a shortcut that displays all direct reverse dependencies of the focussed element in the left pane.

Are you aware of the w shortcut of the nix-tree? It doesn't use the left pane, but still shows the paths from the selected path to the roots ("roots" meaning the paths that you invoked nix-tree with, defaulting to the current system and profile). That's what I use if I need to figure out why my system depends on something.

[dschrempf]

I was not aware of this shortcut, and it somewhat fulfills this need. However, I can not really start nix-tree on my root because it takes about 3 minutes. I always use the specific path I am interested in, and essentially, it would be great to have the w key feature, even when running nix-tree on a specific path. This could be achieved by tracking the reverse dependencies.

[utdemir]

However, I can not really start nix-tree on my root because it takes about 3 minutes.

I think this is the root cause. There really is no excuse of nix-tree taking this long. We have an annoying quadratic algorithm to calculate the "added size", and I believe there's a linear solution but I did not get to implement it.

I think solving the performance issue, then it might solve your problem too.

I always use the specific path I am interested in, and essentially, it would be great to have the w key feature, even when running nix-tree on a specific path.

I really think "reverse dependencies" without a specific "root" does not make much sense, as store paths that are not reachable from your GC roots are only incidentally there. However, you are right that it is very sensible to ask for the case where the roots might be "all gcroots", or "my current system/profiles".

So, I feel like you'd invoke something like nix-tree --gcroots, and do a / to search for the derivation you want (or we can also have something like nix-tree --gcroots --focus /nix/store/...), and use why-depends.

However, as you mentioned, currently it really is not feasible to run nix-tree over the entire gcroots; and that has to be fixed. Assuming nix-tree is fast, would you be happy with the above workaround?

[dschrempf]

I think that would be a good solution! Usually, I have to find the store path anyways before executing nix-tree, so searching for the derivation from within nix-tree is a good alternative.

[utdemir]

@dschrempf Thanks, I will create an issue for the optimisation.

(By the way, it seems like you're both an Haskeller and use graphs; and coincidentely the performance issue of nix-tree is also about calculating a number over a DAG. I will try to write a small post on the problem, to ask your opinion :))

[dschrempf]

Haha 😄, I would be glad to help (but I am not sure if I can). I close this for now since you will anyways open another issue.

[KiaraGrouwstra]

looks like this can be done with nix-store -q --referrers <store path> (or --referrers-closure)