This should probably be moved to be a perSystem arg somehow, FYI. If you only use/support x86_64-linux it’s OK, but still not ideal flake-parts.
You’re totally right this is just my home-manager flake currently, which I do plan to merge with other things but I should move that somewhere better down the line.
1 Like
Assumed it was something like that, just wanted to make sure that people reading this thread didn’t just copy that part verbatim. 
The important part that makes this work is the nativeInputs line. That is a slight deviation from classic flake-parts.
1 Like
it’s dramat. I was close to back to ubuntu. Gemini told me how do it with my configuration.nix
If you feel you have a good pattern, feel free to PR it as documentation 
I’m still not quite sure how to pin the inputs through this mechanism. I haven’t properly read through the documentation but thats my next steps.
Edit: it looks like there’s no pinning. It’s just using follows logic to recurse the graph.
This could quickly make issues that are hard to debug. The documentation is also not very clear.
omniflake.pinned.<name>substitutes nothing. Each input is the revision in the flake’s lock file. Use it when a package must be built against the nixpkgs its author locked.
Which flake is it referring to? My flake? the authors flake? If it substitutes nothing what is the purpose of this option? I feel like in order to understand this documentation I need to understand a number of assumptions.
Each input is the revision in the flake’s lock file.
I’ve read this a number of times and the meaning isn’t clear. Is the input the git hash? The flake revision? The lock file’s metadata? If this was written by AI this can be improved.
1 Like
Please feel free to send PR to improve the documentation; it’s a mix of personally written, AI written (mostly stuff in design) and a mix.
Help me curate!
omniflake.pinned.
This means each flake’s graph is exactly as it would be if you were to just add it as an input. No follows. Everything is as the author of the flake intended.
Each input is the revision in the flake’s lock file.
This just means every input of that flake from omniflake then comes from the flake.lock of that flake. Yes it sucks for wording. I’t’s just saying “it respects the upstream’s lock file purely”
I would like to have control over inputs I use. I would like an input pinning mechanism that sets an omni.lock or something.
2 Likes
how is the indexing working? because it seems to ignore projects that have legitimate flakes
an example is deadlock-mod-manager. The official repo has a flake which I maintain, but only two unmaintained old flakes show up in the indexer. The same goes for millenium (the steam client modification). Their repo has an official flake, but only a couple small 1 or 2 star repos show up
If there are issues, please submit a PR with a fix. To my understanding, the automated scraping and indexing is not meant to be an absolute source of truth. There may be many causes why a single flake might be missing from the index. Manual fixes and index maintenance are by design.
1 Like
It is a heuristic to try and get Nix specific projecs; like @Adda mentioned there are lots of reasons some might be missed but 16k+ is a good sample!
All these projects (ab)use the GitHub free tier so they are the limiting factor in what constrains the solutions. People have also asked for nixpkgs-multiverse to index more (nested attributes) but it’s similarly constrained.
I don’t get any $ out of this so I am making what I can with the free tier.
1 Like
This is truly a brilliant idea.
Question how are you ensuring freshness of each flake? Seems like an ai job and not manual work.
Also out of date flakes how is that monitored?
Is there also syntax checking and evaluation with current up to date nix formatting to ensure each flake will evaluate correctly?
But honestly this is cool as ever. Well done
There is a daily job that searched GitHub for more flakes and updates a portion of the flakes; takes about a week for the whole set to update but high visible flakes like nixpkgs update daily.
You can see it on the release page: Releases · fzakaria/omniflake · GitHub
The flakes have to flake lock so that effectively makes sure they evaluate. Those that don’t for various reasons can be audited here: omniflake
Brilliant mate. Really awesome idea.
Is there a way to use the stable versions of nix-darwin and home-manager? Both have branches corresponding to the latest stable release of nixos, but I couldn’t see a way to reference those branches when using omniflake.
Please see Unification · omniflake
I probably should have added a bit more context. The stable branches of nix-darwin and home-manager are specifically designed to be compatible with the corresponding stable release of nixpkgs, whilst there is no such guarantee between a stable nixpkgs and the unstable branches of these projects.
There are checks, for example, in nix-darwin to ensure that the branches match. Or is there some magic in Omniflake that isn’t mentioned in the documentation?
1 Like