Flake architecture issues #9

Open
opened 2026-06-26 21:49:00 +02:00 by Lithium · 1 comment
Owner

Currently as it stands we can't do anything except load normal modules.
If we wanted to our own derivations in pkgs or standalone overlays it starts complaining about the lack of perSystem.

Proposed solution, would be to remove the automatic import of all .nix files inside ./. that we are currently using and moving to a proper structure with system, packages, configurations, home all cleanly separated and individually referred to.

Currently as it stands we can't do anything except load normal modules. If we wanted to our own derivations in pkgs or standalone overlays it starts complaining about the lack of perSystem. Proposed solution, would be to remove the automatic import of all .nix files inside ./. that we are currently using and moving to a proper structure with system, packages, configurations, home all cleanly separated and individually referred to.
Lithium self-assigned this 2026-06-26 21:49:03 +02:00
Lithium changed title from Flake-parts architecture issues to Flake architecture issues 2026-06-26 21:49:40 +02:00
Author
Owner

#21 fixes a few issues that I had with the flake structure.

What's missing at this point are:

  • Recursive package attrsets so that we don't have to individually list all packages.
  • automatically ingesting every nixosConfigurations and homeConfigurations into a single module so that we can instead focus on options rather than making sure that every single configurations are correct.
  • testing overlays (there is already a nixpkgs-xr overlay which we can use for that)
  • concatenate each .nix in the root into parts.nix

For now this stays open. but the priority is now low and can be pushed to later.

#21 fixes a few issues that I had with the flake structure. What's missing at this point are: - Recursive package attrsets so that we don't have to individually list all packages. - automatically ingesting every nixosConfigurations and homeConfigurations into a single module so that we can instead focus on options rather than making sure that every single configurations are correct. - testing overlays (there is already a nixpkgs-xr overlay which we can use for that) - concatenate each .nix in the root into parts.nix For now this stays open. but the priority is now low and can be pushed to later.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Lithium/nixosConfig#9
No description provided.