Currently, flakes are evaluated in pure mode and have no function arguments (other than the computed set of flake dependencies), so it's not possible to do things like:
- Use
builtins.currentSystem.
- Access
~/.config/nixpkgs/{config.nix,overlays}.
- Access command line arguments passed via
--arg.
Thus we need a controlled way to pass arguments to a flake. This must not compromise hermetic evaluation or the ability to aggressively cache evaluation results. For example, the arguments passed to a flake should be unambiguously hashable to produce a cache key (such that (flakeClosureHash, argumentsHash, attributeName) uniquely determines the evaluation result).
For replacing builtins.currentSystem, however, we don't necessarily have to rely on a function argument. Instead, a flake could simply provide packages/derivations for all platforms that it supports. This is feasible thanks to laziness. For example, the nixpkgs flake would provide attributes such as packages.x86_64-linux.hello and packages.x86_64-darwin.hello rather than a single packages.hello that depends on a function argument. (This is an approach familiar from Hydra jobsets.) The nix UI can select the appropriate set automatically (e.g. nix run nixpkgs.hello will select nixpkgs.provides.packages.$system.hello.)
Currently, flakes are evaluated in pure mode and have no function arguments (other than the computed set of flake dependencies), so it's not possible to do things like:
builtins.currentSystem.~/.config/nixpkgs/{config.nix,overlays}.--arg.Thus we need a controlled way to pass arguments to a flake. This must not compromise hermetic evaluation or the ability to aggressively cache evaluation results. For example, the arguments passed to a flake should be unambiguously hashable to produce a cache key (such that
(flakeClosureHash, argumentsHash, attributeName)uniquely determines the evaluation result).For replacing
builtins.currentSystem, however, we don't necessarily have to rely on a function argument. Instead, a flake could simply provide packages/derivations for all platforms that it supports. This is feasible thanks to laziness. For example, thenixpkgsflake would provide attributes such aspackages.x86_64-linux.helloandpackages.x86_64-darwin.hellorather than a singlepackages.hellothat depends on a function argument. (This is an approach familiar from Hydra jobsets.) ThenixUI can select the appropriate set automatically (e.g.nix run nixpkgs.hellowill selectnixpkgs.provides.packages.$system.hello.)