Are flakes infectious?

Help
1

I have a flake.nix of a useful packages. It’s the best way I have to build said package and I’ve not exercised a more direct nix derivation.

I also have a nix description for building my OS using nixos-generators. Do I have to transform my nixos.nix (operating system description) before I can include the flake.nix (package) in the OS build?

I’ve tried naive methods of getting a derivation from a flake without success and had similar issues getting a flake version of the OS description. Just knowing which of these paths I should (or must) go down would help.

For the derivation, I’d expect to be able to say systemPackages = [ curl vim (someExpr ./flake.nix) ] but it seems no such expression exists.

For the flake of the os description the well known “attribute ‘currentSystem’ missing” is occurring but the trace doesn’t successfully communicate where or how that occurs, all the trace is in nixpkgs and doesn’t show an “entry point” from my local nix code.

2

You cannot use builtins.currentSystem when using flake by design. Instead you can refer to pkgs.hostPlatform.system inside your NixOS configuration if you need to access the system that the system is built for.

3

@Mic92 Yes, currentSystem not being usabel is understood. What isn’t understood is how to fix it - something unknown in my largish os description is using currentSystem and the --show-trace doesn’t tell me what is doing so. As a result, there is no way to replace the (unknown) call to currentSystem with a call to anything else such as pkgs.hostPlatform.system.

4

Ok, it took some bisecting but:

  boot = {
    # kernelPackages = pkgs.linuxPackages_latest;
    kernelPackages = pkgsNew.linuxPackages_6_4;
    ...

This is the problem. If I use _latest kernel then everything builds but the minute I use a specific version such as 6_4 then I get the “attribute ‘currentSystem’ missing” error. Looking at how to pass a system to a specific kernel version.

1 Like
5

I think you are importing pkgsNew incorrectly. It will try to use builtins.currentSystem if you don’t pass in system argument on import.

6

(If you still have issues, and are able to, please provide the repo and/or flake.nix so we can take a closer look!)

7

There is a way to do the someExpr. It really depends on how you are trying to compose everything, but here are three options:

flake-compat

flake-compat allows for using flakes via an “import ./flake-directory/default.nix”, but this will use the lockfile as-is. Not sure if this is what you want.

overlays

If you are disciplined in your overlays only referencing Nix values (paths are fine) that come from function arguments, ie: nothing from from the outside surrounding scope making it a closure. Then you have something like:

let
someExpr = pkgs.extend ((import ./flake.nix).outputs {nixpkgs=null;other-inputs=null}).overlays.default;
in
[ curl vim someExpr.myPackage]

recipes

I like to have it explicit that I am adopting a “package function” or what I call a recipe and I try to ensure it can be obtained in a flake. This can be either as a flake attribute inputs.myflake.recipe.my-package or import (flake-dir + "/pkgs/my-package/default.nix"). Note that this has no system or latent nixpkgs, thus can be brought in and incorporated into your existing work. In this case you end up with something like:

let
someExpr = callPackage (import flake-dir + "/pkgs/my-package/default.nix") {};
in
[curl vim someExpr]

There are tradeoffs between these, but it should get you started.

1 Like