flake: remove flake-utils dependency

[toastal]

By inlining the for loop from the utility library, downstream consumers do not need to pull in any additional dependencies & bloat their flake.lock files. Some additional reorganizing due to inlining as well—with the net effect of more lines deleted than added.

[toastal]

Diff is slightly easier to follow without white space (indentation needed adjusting since ) https://github.com/ocaml/ocaml-lsp/pull/1226/files?diff=split&w=1

[toastal]

This would need to be added to all downstream users’ flake.lock which is a pretty heavy price for a basic loop.

[toastal]

Not Nix’s defaults (theirs includes 32-bit Linux last I checked), but matches the default systems of flake-utils so the change should have no effect on anyone.

[toastal]

I think these are stubs to speed up the build? I moved them all to packages since it doesn’t hurt while using less recs & temporary attrsets which slow down evaluation.

[coveralls]

Pull Request Test Coverage Report for Build 4083

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 20.384%

---

Totals
Change from base Build 4082:	0.0%
Covered Lines:	4851
Relevant Lines:	23798

---

💛 - Coveralls

[anmonteiro]

By inlining the for loop from the utility library, downstream consumers do not need to pull in any additional dependencies & bloat their flake.lock files.

• flake-utils adds a comparable number of lines to flake.lock than any other flake. I don't understand why this is considered "bloating"
  • flake.lock is a generated file that most people don't inspect, apart from when the git diff changes
• the utility library doesn't provide just "a basic for loop", and this reductionism feels a bit disingenuous; rather, it attempts to settle on a common set of systems that flake-utils users can support, apart from abstracting away the nitty-gritty of specifying the correct structure for systems in flake.nix.

Personally, and subjectively, this PR also affects readability. What was once a single function call to eachDefaultSystem now becomes 3 calls to forAllSystems.

[toastal]

Adding 1 dependency is more than 0 dependency. Dependencies need to be audited & unless you remember to follows downstream will end up with a several versions. …And a lot of things in the OCaml ecosystem I have noticed are depending on this LSP. The defaultSystems flake-utils support doesn’t even match Nixpkgs default systems & with it being explicitly shown, the abstraction makes it more difficult for a downstream read to understand if their architecture will be supported (which is why nix flake init generates its defaults as explicitly outputs.packages.x86_64-linux.hello since the package will be immediately be tested and can only be assured to run on the platform of my machine (not platforms I don’t own like anything Darwin)).

With utilities, we are also talking about a leftPad situation tho… like, sure everyone using that same utility means folks can share logic, but when the dependency disappeared the ecosystem broke despite that utility being a couple of lines of JavaScript. flake-utils.forEach is just a wrapper around a loop while + adding the pkgs to the closure (which this in-file version could add to the closure if that is preferred).

Currently at a physical Nix sprint in Thailand… & for an anecdote I asked, without pretense, a Numtide employee “thoughts on adding Numtide’s flake-utils as a flake input dependency for only eachDefaultSystem” with the response “we pretty much only use flake-parts for [more complicated] stuff now, but no, I wouldn’t include [flake-utils] just for that”. This has also been corroborated in larger community Matrix chats & others spending a part of their sprint culling unnecessary inputs from their flakes in order to remove dependencies (since there is no devInputs, devDependiences, etc.).