I've used flake parts twice - by requirement of other things using it.
I've seen people describe it as a "flake-cancer that's spreading faster than flake-utils"
and... I just don't get it.
Why would I want flake parts; what's it going to do for me besides add dependencies to evaluation?
SELL ME YOUR TOOLZ
and... I just don't get it.
Frankly, I have the same problem. Maybe we can have this thread and go for an explanation?
Because @Srid and been working with it for a while now, and is working fairly closely with @Robert Hensing, the author of it. (But he hasn't been logged in here for a while I think)
Module system
I don't get it either - you can do it as easily without the library
The module system already handles stuff for system abstractions, so :man_shrugging:
Hi :wave:
To quote https://flake.parts
Flakes are configuration. The module system lets you refactor configuration into modules that can be shared.
It reduces the proliferation of custom Nix glue code, similar to what the module system has done for NixOS configurations.
It makes it easier to add Nix logic that other people have already written to a flake that uses it.
Flake parts by itself doesn't do much, because it's only an interface. Nobody needs it. Everyone could write their flakes by hand, and that's fine, especially when the flakes are simple.
Now suppose you're adding pre-commit hooks to five flakes. If those are all framework-less flakes that only depend on Nixpkgs or whatever, you'll have to figure out for each of them how their Nix code is structured, to find where to put the checks.<system>.pre-commit-run
derivation and where to put the shellHook
, which variables are in scope in those places, etc.
With flake parts, that's reduced to simpler steps: add its module to inputs
and imports
, then find the shell, add [config.pre-commit.installationScript](https://flake.parts/options/pre-commit-hooks-nix#opt-perSystem.pre-commit.installationScript)
to shellHook
and you're done. Always the same.
It doesn't standardize a nix shell interface yet, but that could totally be done, and the "gluing" part of the job is just inputs
and imports
.
@Srid is working on a CLI so that it's just a single command to add a module with some defaults (forget about inputs/imports).
It will also find the right modules based on the files you already have, and have templates for things you want to create in your flake, like a new custom python package for example.
Andreas said:
Because Srid and been working with it for a while now, and is working fairly closely with Robert Hensing, the author of it. (But he hasn't been logged in here for a while I think)
I'm always available for flake-parts related questions. Srid asks good questions, but I don't have much time to contribute to his projects.
I've only really contributed a bit of code to haskell-flake
, which I use in hercules-ci-agent
.
Thanks for coming by @Robert Hensing ! It's always good to have the author of a project to talk to :smile:
That's a good explanation :+1:
Essentially flake-parts moves us a substantial way towards better DX, especially in non-trivial flakes. In the long run, a total solution may emerge. Upstream could get a flake module system and/or something better than Nix can emerge (the idea David was talking about).
Robert Hensing said:
It doesn't standardize a nix shell interface yet,
inputsFrom
can be used to somehow mitigate that.
Ah, I get it now. I do have a lot of glue code in my repositories, and I suppose I could swap that with flake-parts
yeah the glue code problem is a real issue, I get that. But I might have to look a bit harder at flake-parts to see if I can envision it being the go-to solution for me.
Because just from my subjective impression on this one here from @Srid
Essentially flake-parts moves us a substantial way towards better DX, especially in non-trivial flakes.
To me looking at the non-trivial flake repos using flake-parts, it still looks like a lot of glue code tbh.
Last updated: Nov 13 2024 at 11:45 UTC