ocaml-lsp
ocaml-lsp copied to clipboard
ocaml
flake: remove flake-utils dependency
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.
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
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
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.).