Move away from the self-referential locking in sub-flakes #416
Description
After updating to 2.18 (or above), CI fails with
error: in pure evaluation mode, 'fetchTree' will not fetch unlocked input 'path:../../?lastModified=1'
Context
- In this repository, we early attempted to use sub-flakes to sparsely inject inputs only to the (sub-)flakes, where they where needed.
- This allowed subflakes to access newer versions of an input that was not yet suitable for the main flake (e.g. due to stability reasons).
- It also allowed the subflake to load inputs that should not have increased the lock file of the main flake, because lock file size is of concern for a library like Standard. On a side note, this is also way some flake inputs are "blanked" and why there is a user-facing alert mechanism to adivse on adding these inputs in paisano-nix should the user wish to use certain functionality
However, it appears that the use of sub-flakes has been made completely impractical as of Nix v2.18. It was always a bit of an exotic use and Nix didn't do the "right" thing (imho) to maintain the trust scope of the git repository and render relative links between flakes within that repo boundary trusted by default (meaning to waive the need for a lock or hash).
This repo hacked around this by choosing a sequence of locking the main flake and then re-locking the subflake with the lock of the commited main repository and thereby feeding the required lock of the anyways trusted own git repository into the subflake.
We should investigate how this evolved and is done today, then implement a new and more future-proof mechanism and ultimately leave this "hack" behind.