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).
Despite the original flake-file name, it now supports stable Nix non-flake environments. code example.
This is possible via integration with @GoldsteinE’s unflake project.
The example shows usage without flakes nor flake-parts.
This feature enables people writing modules that define flake-file.inputs to be able to share those modules, and inputs will propagate into whatever the final module consumer uses: flake.nix or unflake.nix or npins (via unflake --backend=npins).
release v0.3.0
Release v0.4.0 now supports generating from same options into different backends: flake.nix, unflake, npins, nixlock, and also templates for each of them.
Each of them has an app write-flake/write-unflake/write-npins/write-nixlock that can be used directly by our bootstrap nix-shell, so you can try generating directly from some /some/flake.nix you already have into a temporary ./testing directory:
mkdir testing
nix-shell https://github.com/vic/flake-file/archive/refs/heads/main.zip \
-A flake-file.sh --run write-nixlock --arg modules /some/flake.nix --argstr outdir ./testing
How about having a single program that would generate the lock file ? No matter which backend is used.
Hey Pol, which lock file do you refer to ? flake-file is not a fetcher/inputs-lock tool, and each backend has its own locking mechanism, flakes (flake.lock JSON), unflake (unflake.nix), npins (npins/sources.json), nixlock (nixlock.lock.nix), different languages and different features. flake-file is just about giving people an option to share dependencies defined on nix modules and propagated to whatever their project uses be it flakes or other non-flake tools.
Oh I get you, you mean that the command name is not tied to the backend being used? So that you only use write-lock and it detects what lockfile you are using and delegates to the corresponding app. That looks like a good idea 
I’m slow, sorry. but I guess I got you.
Yes exactly
Done, write-lock detects lock-file and delegates to corresponding backend app.
flake-file has always supported flake input schemas (via lib.types), that was one of the reasons since first released, and for a few days now since we added our bootstrap command, it also has support for output schemas, I just today took some time to actually mention them on the getting started guide. And also added a working example at templates/minimal. Change the hello output, run nix flake check, no magic there just outputs being type checked by the Nix module system, works with Lix, CppNix, DetNix, (maybe one day with my GoDNix if I ever get time to finish it).