checking cache keys should not cause a build about peru HOT 3 CLOSED

Yes, we could write nothing-actually-built cache keys as well as actual-input-trees cache keys, and we could check both at build time. The former will usually prevent the latter from getting hit, but the latter can help in cases where e.g. two different modules turn out to provide the same outputs.

from peru.

Note that nothing-actually-built cache keys can't be computed for anything that depends (even transitively) on an overridden module. Actual-input cache keys can, though.

from peru.

https://phabricator.buildinspace.com/D57 is reorganizing cache key behavior. The remote module will now cache only its fetch tree, so imports will not be part of that cache key. The imported modules will also independently cache their own fetch trees, and then the shared tree merging code will cache the merged result.

Nothing-actually-built-cache-keys (as opposed to actual-inputs-cache-keys) behave badly in the presence of overrides. They're either not going to change when the override changes, which would be broken, or they won't be computable at all. They will also cause a problem we've tried to avoid before, where different modules have different cached views of the same dependency. Actual-inputs-cache-keys are the more robust model.

We've moved in a direction where different parts of the program do more granular caching, so the notion of One Big Key that represents a module or a target is no longer really useful. Cache keys are now more of an implementation detail of classes than they are something that classes expose.

from peru.