Dev-only dependencies

[roberth]

Avoid loading dev-only modules by deferring those; when checks etc are accessed.

• devImports : deferredModule
• override flake.checks and flake.devShells in the main eval; choice of attrs should be generalized
• what about apps?
• do this at the perSystem level too?

This will work best with

• Reuse input lock files NixOS/nix#7730

[roberth]

flakeModules may suffer from a similar lack of laziness and should perhaps be considered as a "class" or "context" of its own.

Both it and dev-only dependencies move towards a situation where the top level attributes are more controlled, and have to be enumerated somewhere in order to be published on the flake.
It's perhaps worth considering to model these dependency phenomena explicitly within the top level modules somehow. The genericity seems warranted because the internal dependencies may differ between flakes. I'm concerned about the complexity of such a solution though, and about the potential for bad interactions (although that might just be fear talking at this point).
To develop this, it's probably best to start with dev-only dependencies and perhaps later generalize it, if feasible.

[roberth]

Here's a possible implementation

• Make dev-only dependencies lazy and private hercules-ci-agent#516

The flaws are

• Compensating for bad subflake support in Nix, while the subflake is actually a workaround for Reuse input lock files NixOS/nix#7730
• Re-evaluating the modules without restriction could let the dev modules make changes to e.g. packages, potentially defeating checks / CI. While this is nothing new - you could test mypkg.override foo instead of mypkg, it does make it possible to override something by mistake.

Ideally it would reuse the base evaluation's option values, while also setting readOnly = true on the pre-existing options. Only specific options, such as checks and perSystem.checks would have their definitions forwarded, allowing merging (instead of forwarding the final option value).

a situation where the top level attributes are more controlled, and have to be enumerated somewhere in order to be published on the flake.

Not sure. They may be quite orthogonal despite serving similar goals.

later generalize it

Had no problem generalizing hercules-ci/hercules-ci-agent#516 (mentioned at the start).

[roberth]

🎉 You may now use flake-parts.flakeModules.partitions to achieve this.

---

I'm debating whether to add an opinionated module that sets

partitionedAttrs.checks = "dev";
partitionedAttrs.devShells = "dev";

and perhaps add a convenience alias dev for partitions.dev.module.
Not sure about the other options in partitions.dev though. Maybe set opinionated defaults like extraInputsFlake = self.outPath + "/dev";? Might be fragile.