Nix: structuring Flakes with Blueprint

Links
21

Probably not as-is, but I can see blueprint becoming a source of inspiration (among other projects) when designing the next iteration of flakes, once the current implementation has been marked as stable. Ideally flakes would be low overhead out of the box.

4 Likes
22

once the current implementation has been marked as stable

Iā€™ll see you in 2060!

23

Hi. Iā€™m new to NixOS, and right now Iā€™m deciding on what to use as my starter config, since Iā€™m using just default configuration.nix right now, with some added options.
Iā€™ve stumbled upon Misterio77ā€™s starter-configs at first, but after reading some posts and issues, Iā€™ve found out about this nixpkgs problem. Iā€™m still looking for a template that would implement the best practices of NixOS, and Blueprint seems promising, but, as I understand, it has the same problem @waffle8946 has wrote about.
As I am a new user, itā€™s hard for me to wrap my head around. Could someone explain it to me?

  • Does this mean I shouldnā€™t use this project?
  • What are the practical consequences? Does it mean that the packages are stored multiple times on disk, or downloaded multiple times?
  • Is there a better alternative?
24

I can give one example:

I have a blueprint with a host that has is cross compiled (its a resource constrained pi):

# ./hosts/pi-homeautomator.nix
{ pkgs,... }: {
  nixpkgs.hostPlaform = "aarch64-linux";
  nixpkgs.buildPlatform = "x86_64-linux";
}

Now i want to consume a package from the flake. If itā€™s an overlay this just works. In another scenario Iā€™m now stuck.

3 Likes
25

I wonder if we would make packages defined using nixpkgs fixpoint lib, as opposed to the built in fixpoint in flakes; then at least the result can be spliced and you can call extend on the set or convert the set to a pkgsCross version. The problem is that flakes builtin fixpoint (the inputs param) makes all the nixpkgs cross compiling infra useless as you canā€™t splice your package even if you neatly define it with mkDerivation. You need the callPackageWith stuff

1 Like
26

I think I would go deeper and look at how to get access to the flake fixpoint to make them programatically overridable.

Blueprint could solve this by having its own interface. Have a compatibility layer that maps the blueprint outputs to flake outputs. And if any other input is a blueprint, detect that and bypass the flake schema entirely. Thatā€™s something I have been experimenting with, but it also introduces more complexity and questions to solve.

The 1000 instances of nixpkgs problem is only an issue for producers. Aka flakes that are going to be consumed by other flakes. In your case, this is the root flake, so you donā€™t have to worry about this.

Generally speaking my recommendation is not to worry too much. Youā€™re going to mess things up, and itā€™s going to be fine. Pick a started template where you feel you can get things done, itā€™s always possible to move things around later.

If you pick blueprint, donā€™t hesitate to create issues whenever you get stuck, so I can improve the documentation. I love getting the fresh userā€™s perspective on things.

4 Likes
27

I think I accidentally stubled onto some nice design, because I keep getting feedbacks like this (I asked Oli if I could share):

image

5 Likes