The top-level flake.nix contains an app (bootstrap-client-project) which creates a new client project with the inner flake.nix placed at the new project’s root.
When developing, the interactive cycle for testing the synergy between these two flakes is very onerous.
Firstly, the template’s flake has the top-level flake as an input, via its official in-the-cloud URL, but for local development iterations, we have to change it, temporarily, to point at the parent flake on the local file system. This is very annoying and error prone.
Secondly, the steps needed to check how any change in the parent repo affects the client repo, look something like this:
nix run path/to/parent/project#bootstrap-client-project path/to/new/client/project
I would like to shorten this cycle (whenever possible) to some variation on this theme
nix run path/to/parent/project/templates/basic#client-package
Fails: Uses the top-level flake’s root (rather than the inner flake’s root) as the source.
nix run path/to/parent/project/?dir=templates/basic#client-package
Error: no matches found
At the moment, bootstrap-client-project copies the inner flake verbatim into the new client project, but eventually we expect some generic values to be replaced by client-specific ones, at which point it seems that the in-tree verification process will become impossible anyway.
Do you have any advice on how to streamline the development experience of such interdependent flakes?
What you want is a subflake. I have long talked about how subflakes should be implemented in Nix with @tomberek. The second flake.nix underneath, (subflake), needs not to have a flake.lock, but since the nix cli does not know what a subflake.nix is, it will always generate a flake.lock, which breaks everything. The subflake.nix needs to have no lock, and inherit the lock from the parent, which is why it has to be a unique and separate concept from a flake.nix.
I added the following PR which adds a function that makes it easy to call subflakes, you can read about it there.