Recursive way to set override an input using flakes and follows

Help
1

Hello all, I am new to nix and am trying to setup a distribution and build environment using nix.

I am trying to achieve the following build hierarchy:

BASE
|
Foo (Uses Base as an Input)
|
Bar (Uses Foo as an Input)

There are different refs of base added to my private registry.
for ex:

flake:base/0.1.0
flake:base/0.2.0

I need to be able to rebuild the entire stack based on this base package and I was expecting to use the --override-input option in nix to achieve this. Following is a very simplified example of what I am trying to achieve. I have only included very sparse flake files in the interest of brevity.

base

{
  description = "Base.";
  inputs.nixpkgs.url = github:NixOS/nixpkgs?ref=23.05-pre;
  outputs = {self, nixpkgs} :
  ...
}

foo

{
  description = "foo.";
  inputs.base.url = "flake:base/1.0.0";    # Added to the registry
  inputs.nixpkgs.follows = "base/nixpkgs";
  outputs = {self, nixpkgs, base} :
  ...
}

bar

{
  description = "bar.";
  inputs.base.url = "flake:base/1.0.0";
  inputs.nixpkgs.follows = "base/nixpkgs";
  inputs.foo.url = "flake:foo/0.1.0";   # Added to the registry
  inputs.bar.url = "flake:bar/0.1.0";   # Added to the registry
  outputs = {self, nixpkgs, base} :
  ...
}

Now when I build the bar app using the override inputs option:

nix flake metadata bar/0.1.0 --override-input base/nixpkgs github:NixOS/nixpkgs/91c61da251bfad8b1bbcbdbd54d19cdc76fe2f50

Nix only overrides the base/nixpkgs input at the very first level and is not reflected in the nixpkgs of bar.

Is there any way I can achieve something like this? I am sure (or hoping) I have overlooked something which could be of use/help.

2

I think your example are a bit off, as your bar does not reference foo, like it should according to your concept diagram above. Yet it references itself…

I should also warn you, more complex setups involving transitive dependencies and/or follows still have a number of outstanding bugs last time I checked. You may want to check the nix issues on github.

3

Thanks @tejing , I have corrected the snippet.

For a package manager, this should be a common pattern, no? Is there a better way to tackle this in Nix?

4

Transitive dependencies of packages work fine. Of flakes, less so. Flakes are an experimental feature…

5

foo and bar are in no way linked to base.

You probably want foo.inputs.base.follows = "base" in the flake file.

Alternatively to override the registry --override-flake.

6

@NobbZ , yes i did think about doing that however, I wanted something less explicit. I will have many dependencies and dont want to have to do dep1.inputs.base.follows = base for all dependencies in a flake.

Hmm…did not think about overriding the registry. Now that you mention it, it might solve the issue.
Would I override flake as follows?

nix flake metadata bar/0.1.0 --override-flake base/0.1.0 base/0.2.0

The above doesn’t seem to have any effect. Is that the right method to do this?

7

I generally do not work with the registry from within a flake, as it basically re-introduces the worst of channels back into flakes, system state.

And trying to be “less explicit” seems to be the wrong approach to me.

1 Like
8

I think under certain circumstances, some patterns make sense?

I agree that explicit is better but in this case, explicit brings along a tonne of redundant boilerplate. I would have to override the inputs of each of my dependency in each flake file. Additionally, this assumes the person writing the flake file will have knowledge of the inputs of each of the flakes.

I want to basically consolidate this, instead of having lines upon lines of dep1.inputs.base = base just override this at one location in my project. In this case, the flake.nix of base would be explicit however we reduce the boilerplate involved, no?

When using nixpkgs, we are pinning the versions inside the flake.nix, I dont see the issues related to channels creeping unless don’t specify the sha? (again, I could be wrong with my limited experience and knowledge of Nix)

Thanks for all your suggestions :smiley: