allow non-trivial expressions in flakes

[KiaraGrouwstra]

lifts flakes' restriction allowing the use of only trivial syntax, which has particularly affected its inputs.

Motivation

• lifting flakes' syntax restrictions to allow non-trivial nix expressions, particularly for the purpose of declaring inputs, came up as an alternative approach that came up in [RFC 0193] TOML Flakes rfcs#193.
• i looked into this in the context of figuring out if it would be possible to allow hybrid means of dependency management, e.g. managing dependencies outside flake inputs yet still allowing to override dependencies using the flakes interfaces (CLI flag --override-input, inputs attribute .follows) as well - sort of as a reverse flake-compat.
  • edit: it seems url = "file:/dev/null"; works

Context

• shifts responsibility on evaluation performance to flake authors.
• making use of the ability to use non-trivial expressions may or may not work with existing tooling presuming non-trivial expressions. so far the one example that comes to mind for me there would be flakehub's cli, which contains functionality to write to inputs to update them. (logically, one probably should not expect to set their entire inputs section using some function call while simultaneously using tools to write to inputs to update them.)
• i don't actually know if this change might be considered desirable - but maybe a draft PR people could try might help people experiment so as to get a better sense of that.
• an additional consideration here could be the stance of flake-implementing forks such as Determinate Nix and Lix, as introducing inconsistencies before the introduction of versioning and a central spec could lead to incompatibilities.
  • this might not be as much of an issue for unpublished flakes, but would be more relevant for libraries expected to be consumed by others, potentially running various nix flavors.
• also see previous discussion at What language is flake.nix written in? #4945.

[edolstra]

I don't think this is a good idea. It's very predictable that people are going to abuse this in horrible ways, such as doing IFD during the computation of the inputs. So commands like nix flake metadata or nix flake lock might not only do an unbounded (possibly non-terminating) amount of evaluation, but also do arbitrary builds.

[KiaraGrouwstra]

thanks for the feedback - i'll close then.