6bc98c7fba
This makes it more useful. In general, the derivation will be in one store, and the realisation info is in another. This also helps us avoid duplication. See how `resolveDerivedPath` is now simpler because it uses `queryPartialDerivationOutputMap`. In #8369 we get more flavors of derived path, and need more code to resolve them all, and this problem only gets worse. The fact that we need a new method to deal with the multiple dispatch is unfortunate, but this generally relates to the fact that `Store` is a sub-par interface, too bulky/unwieldy and conflating separate concerns. Solving that is out of scope of this PR. This is part of the RFC 92 work. See tracking issue #6316 |
||
---|---|---|
.. | ||
build-remote | ||
libcmd | ||
libexpr | ||
libfetchers | ||
libmain | ||
libstore | ||
libutil | ||
nix | ||
nix-build | ||
nix-channel | ||
nix-collect-garbage | ||
nix-copy-closure | ||
nix-env | ||
nix-instantiate | ||
nix-store | ||
resolve-system-dependencies | ||
toml11 |