If I’m understanding what it does, not really? It seems to evaluate an expression in a multithreaded manner and return each individual derivation in an attrset as soon as they are available (as opposed to when the whole thing finishes) but it doesn’t appear to do any dependency tracking at all. It prints the derivation attributes (inputDrvs, etc) but that’s information we could already get.
True, and we currently have no way to get the results of that scan (rather than the whole closure) without reimplementing the entire path scanning infrastructure ourselves. Admittedly the only usecase I can think of at the moment is a marginal disk space reduction if you are sure your derivation depends only on inert files and not other executables, but I included it for conceptual symmetry with the other two.
Almost, but not quite. inputSrcs are instantiation-time dependencies. inputDrvs rely on string context for dependency resolution, and it is possible to intentionally or unintentionally lose it. I could be wrong on this, but since .drv creation and string interpolation is done at eval-time, if that “invisible” inputDrv itself depends on some kind of eval-time fetcher (which now cannot reach the internet), you can get an evaluation failure. More importantly, there is currently no native means of actually obtaining inputDrvs and inputSrcs information. Your only options are external tooling or fragile hacks that rely on an implementation detail (the .drv format).
IFDs introduce arbitrary Nix expressions, not just strings that can hold context. For instance, I can import a .nix file produced by a derivation containing a description of another derivation, which I then go on to use. Not being able to build that .nix file is an evaluation failure, but it leaves no trace on the string context. More egregiously, I can straight up write a .nix file containing a single extremely long string literal that is actually just a binary (to get around readFile preserving context). Even if the imported derivation did absolutely nothing at all, I would still need it to instantiate successfully! (hence the term “instantiation-time dependency”)
As I have demonstrated, it is currently not possible even with external tooling, since we lack certain information available only to the Nix evaluator. Even if it were, I think the usecase is significant enough to justify a Nix Language solution, rather than, say, one involving processing nix eval output with jq. If you search “nixos offline rebuild” and “nixos get all sources” you will see that this is at least a somewhat commonly requested feature. It was either add new behaviour or modify existing ones (breaking compatibility), and I felt that this was the most elegant solution.