Development only flake inputs or different category of inputs

[terlar]

Is your feature request related to a problem? Please describe. When you developing a flake that will be used by other flakes your flake might come with more inputs than the end-user needs.

Several inputs might only be needed during development/testing. Examples:

• Even in this repo there is a flake input for nixpkgs regression test: https://github.com/NixOS/nix/blob/master/flake.nix#L5
• If I create a library function or an overlay I might want to test towards multiple nixpkgs releases.
• I might be using something like devshell for managing my development dependencies.
• I might use flake-compat and use the flake to pin down the source.

Describe the solution you'd like I'm not sure how to verify that those inputs you use will only be used for devShell, checks or hydraJobs. But I guess when opting out from inputs you would need a way to determine what inputs needs to be pulled in.

Describe alternatives you've considered Creating multiple standalone flakes, e.g. one flake in a folder named devshell, another flake in a folder named tests. But unfortunately that makes the main flake not supporting the nix develop and nix flake check commands.

[edolstra]

We cannot have dev-only inputs without dev-only outputs (since we don't want to pass the dev-only inputs to the non-dev outputs). I.e. we would need a devOutputs function in addition to outputs. But it seems better to use a subflake since that's a more general solution.

[Kha]

Thanks to lazy fetching of flake inputs, this issue is less severe than in other package managers such as Cargo. The major remaining annoyance for me when using development or other "private" kinds of inputs is that they are copied to any parent flake's lockfile and printed in commands such as flake update. Is it actually strictly necessary to copy inputs? I can see that at least for inputs referenced in external follows declarations, copying the lockfile entry may avoid fetches of the input.

[terlar]

I guess it is the point brought up by @Kha that bothers me most as well. If you have a flake that consumes several other flakes and each of these flakes have a lot of "private" inputs, that flake's lockfile can become quite unwieldy.

When using a sub-flake the user experience also potentially go down slightly, but it is not too bad. Might just be that I haven't learned about all the sub-flake patterns yet.

[edolstra]

Yeah the usability of subflakes is not very good at the moment, so we need to improve that.

[roberth]

One way to alleviate this is by allowing builtins.getFlake (toString ./test-dependencies) in impure mode when a flake.lock is in that "subflake".

Nix 2.7.0 prints the following, despite lock files being present in both directories.

error: cannot call 'getFlake' on unlocked flake reference '/nix/store/8fhx9h1qm0f2mra456dbbhkjvdhijjqm-source/test-dependencies', at /nix/store/8fhx9h1qm0f2mra456dbbhkjvdhijjqm-source/flake.nix:17:20 (use --impure to override)

[roberth]

annoyance for me when using development or other "private" kinds of inputs is that they are copied to any parent flake's lockfile and printed in commands such as flake update.

Perhaps the design choice of always flattening the lock file could be reconsidered. The dependencies of an intermediate dependency are usually only referenced when the intermediate dependency has already been fetched, so it wouldn't hurt performance to use those lock nodes instead of a copy in the root flake.

This might make a solution like https://github.com/NixOS/nix/pull/6326 redundant.

I might want to test towards multiple nixpkgs releases.

This could be resolved with more application of mapAttrs and/or nested attribute sets in checks (checks.<system>.nixos-unstable.vmTest).

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/flakes-and-pollution-of-downstream-projects/35411/12