Stream: flake-parts

Topic: Make me a beliver


view this post on Zulip John Bargman (Jul 06 2024 at 05:38):

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

view this post on Zulip Andreas (Jul 06 2024 at 09:35):

and... I just don't get it.

Frankly, I have the same problem. Maybe we can have this thread and go for an explanation?

view this post on Zulip Andreas (Jul 06 2024 at 09:36):

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)

view this post on Zulip Srid (Jul 06 2024 at 09:37):

Module system

view this post on Zulip RGBCube (Jul 06 2024 at 12:03):

I don't get it either - you can do it as easily without the library

view this post on Zulip RGBCube (Jul 06 2024 at 12:03):

The module system already handles stuff for system abstractions, so :man_shrugging:

view this post on Zulip Robert Hensing (Jul 06 2024 at 12:54):

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.

view this post on Zulip Robert Hensing (Jul 06 2024 at 13:01):

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.

view this post on Zulip Andreas (Jul 06 2024 at 13:33):

Thanks for coming by @Robert Hensing ! It's always good to have the author of a project to talk to :smile:

view this post on Zulip Srid (Jul 06 2024 at 14:00):

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.

view this post on Zulip RGBCube (Jul 07 2024 at 12:05):

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

view this post on Zulip Andreas (Jul 07 2024 at 12:16):

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.

view this post on Zulip Andreas (Jul 07 2024 at 12:18):

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: Dec 03 2024 at 16:21 UTC