Passing options to flakes

Help
1

I’ve been trying to keep up-to-date with the flakes RFC and I’ve got a question about it but the thread there seems to be getting too long, so I’d rather ask my question here.

I’m currently heavily relying on the possibility to pass options to nix-builds via the command line or via environment variables.
As far as I understand this is something that won’t be possible anymore when flakes are merged (at least not using nix build, which will be flake based).
While I understand the implications of using impure builtins such as getEnv as part of a nix expression to go against the hermetic property of flakes, I don’t really understand why using explicit options on the command line is something that we cannot have anymore.

nix build #hermetic
nix build --argstr extraFlags "-01 -someotheroption" #still hermetic apart from the explicit argument

Would someone shed some light on the why and sketch possible workarounds?

7 Likes
2

You can bring a flake into scope using the getFlake builtin and then
call functions exported by the flake.

3

I’d like to bump this since it does not appear to have been resolved.

I also have a workflow where I build a package that has multiple different options that can be disabled or enabled at compile time. It is convenient to be able to pass these different options as nix build --args, but with flakes this doesn’t seem possible.

How are other people working around this? Have you just gone back to nix-build for these use-cases?

There seems to be a couple issues about this on the Nix issue tracker, but no one has suggested any compelling work-arounds:

1 Like
4

For boolean flags, a somewhat workable workaround is to use nested/recursive derivations instead: nix build .#prog.debug.noFoo

2 Likes
5

As far as I am aware, this is by design. A lot of Nix features (nested package sets, …) have been removed from Flakes to make evaluation caching easier. A function is fundamentally not-cacheable, so flakes has no first class support for passing arguments.

6

We also depend on this feature

3 Likes
7

FYI: regnat proposed to introduce a new type of flake input nixExpr, which would solve this problem. Allow plain Nix expressions as flake inputs · Issue #5663 · NixOS/nix · GitHub

6 Likes
8

@thufschmitt posted an issue on the Nix issue tracker suggesting a solution to this: Allow plain Nix expressions as flake inputs · Issue #5663 · NixOS/nix · GitHub

My understanding is that this would allow a new input type that would accept a Nix expression.

edit: Oops, this is exactly what @knedlsepp just posted… Sorry for the spam.

2 Likes