End game for inputs in flakes?

Flakes were originally designed to federate Nix packages and not have everything go through nixpkgs (my understanding).

What I don’t understand is what’s the end-game for inputs in the flake.nix ?
Is there a way to manage a massive list of inputs ?

I have flakes that get into the 10-20 and it feels too much the way it’s shown and managed.

1 Like

The best way in my opinion is to revise that list and trim it down to the inputs you actually need…

Other than that, what is the perceived problem with them? My biggest flake (system and home configuration) currently has 13 distinct inputs, and I have no problems managing those.

Where “managing” means, just leave them sit at the bottom of my flake.nix and never touch them again after they have been added, unless I know that I do not need them anymore…

The major workload will be dealt with by nix flake update, which again happens on CI…

3 Likes

this is a flash of genius, of course they don’t have to be first, even if it makes sense as a starting point.

3 Likes

In one of the projects we had flake.nix only with inputs and outputs = import outputs.nix;

Not that I recommend but its something

all in all, I recommend using something like flake-parts and having outputs very minimal, basically used to import other modules

if you really do have a massive list of inputs, maybe consider using some project that pins those inputs, especially if those inputs arent flakes

That’s why i say “end-game”.
Is it for nixpkgs to be replaced with a federated flake system (i.e. FlakeHub registry)
If so, that list would explode…

yeah, i really hear you - i have had similar questions/thoughts

flakes are advertised as a great way to lock many inputs… oh but caveat… don’t lock many inputs! :man_facepalming:

i keep hearing that lazy trees will save us… so i keep waiting… year after year…

1 Like