My mind says no but my heart says yes
My mind says no but my heart says no
Update:
I’ve added a flake-file.flakeModules.dendritic module. Including it will configure a full dendritic setup on your flake: Add flake-parts, import-tree, the output function loads ./modules.
Everything enabled just by including it:
imports = [ inputs.flake-file.flakeModules.dendritic ];
the ./dev subflake we use for running checks uses exactly this. And is also provided as a dendritic template.
I’m happy people’s heart and mind is able to say No, that’s healthy. flake-file does not try appeal to everybody (it is not intended to). It’s a project (just like all other things I’m doing: import-tree, dendrix and now flake-file) that I am doing out of love for NixOS newcomers (people first, but also as my two-cents to help improve NixOS adoption). Having newbies include flake-parts modules and have everything configured for them (including flake dependencies). So if you are not new to Nix, probably this does not have any value to you, and that is good, it means you are just not the target market, but that you are, instead, on the side of nix-knowing people that can actually help people who don’t know.
So there it is, people can share flake-parts modules that contribute the user flake.
You’re on fire mate !
Haha, it’s more like my brain that gets hyper-focused at times (or obsessed on things), I believe 
I’ll have pause a bit my current Nix projects, tho. I have pending work to do on my fx-rs Rust Algebraic Effects System. I’m in the middle of implementing Quantified Effect Handlers (Affine and Linear) and have to prepare a paper for a conference on it.
I’d been considering doing this, myself. It honestly seems like the most workable solution to the inability to calculate flake inputs.
I don’t think I’d be totally happy with my solution unless it worked automatically as a git pre-commit hook, though. And if implemented like that, it would have to handle the case where you’ve git added only some of your changes. git stash push -k should be able to handle that? Anyway, I’m probably going to write my own implementation soon.
in this case it can be used as git pre-commit hook, since mightyiam/files already adds checks (to ensure any file generated by it are up to date). so a pre-commit hook would most likely just do flake check.
EDIT: on the checks generated by mightyiam/files, it re-generates the files in the nix-store and compares (using difftastic) with the files on the current repo (also copied by nix into the store). If there’s a difference, you see difftastic output as failure.
I was thinking more of having the pre-commit hook automatically write the generated file. Though the check is certainly enough to avoid accidental screw-ups.
In that case, just running the mightyiam/files’s derivation perSystem.config.files.writer.drv (in my examples I expose it as packages.write-files) could work.
nix run .#write-files
but now, as you said, you are generating changes inside the hook, haven’t tried if something like that works. A quick guess, is, as long as you are not generating new files (only existing files get dirty) nix should be able to see them as changes in the index. Dunno, maybe I’ll explore this tomorrow and see get back to you if it works.
Update: I made a few changes to the README and tried to clarify some things: Features, Who is this for?, the advantages I see from using it, and a Migration Guide for existing flakes (this one based on what I did on my own repo to adopt flake-file).