[sshine]

There are two kinds of organization happening here that you might not see:

1. All .nix files (besides flake.nix) are flake-parts modules: https://flake.parts/

2. It's not only usable with experimental flakes. Works fine with unflake or trix.

The experimental part of flakes is enabling flake support in the `nix` CLI.

Flakes are also a design pattern in pure Nix syntax that can be evaluated fine without the experimental flag.

If you're curious about this meaningful organization, it's pretty well-documented:

https://denful.dev/

As for the experimental nature of flakes, it's more of a social experiment by now:

https://simonshine.dk/articles/if-flakes-are-experimental-wh...

[toastal]

Flake parts modules means that it’s an abstraction on top of an abstraction, flakes, on top of Nix. Then to need to throw unflake or trix at the problem is more layers & woven dependencies—same for ‘Dendridic’ patterns. If you invert that paradigm, & just import or callPackage Nix files from the flakes, then accessing say a package.nix or module.nix or overlay.nix is trivial for anyone not taking part in your specific design pattern—be it flakes, nilla, whatever. I feel this is another of these situations where engineers want to engineer their way out of messes by adding more code. Rather than a “how do I do X-PROBLEM in flakes?” if the question is “how to do X-PROBLEM is bog standard Nix?” you end up at design that tends to be a lot simpler since the the simpler bits are now decoupled from the framework (which flakes behaves more like); instead, flakes now own its complexity only in its file instead of its patterns ‘infecting’ simple parts (case in point, 2 weeks ago I helped a project get the overlays be compositionally sound by removing a coupling of inputs as a first argument & a self threaded into the package via callPackage). This is why ‘package normal form’ exists for packages in Nixpkgs so any setup can callPackage it… or how overlays already offer more powerful/flexible composition than input.follows which adds to flakes composition problems. With exceptions, Nix itself was already good enough for most cases… it just needed some design guidelines everyone could start reasonably follow (which the experiment post points out is “the good part” (good post btw… hadn’t seen)), except the state of flakes being as the are means they are stuck in limbo as too many projects now rely on it; which I guess that limbo itself means they are stable since all changes insight in-fighting—& all of these forks now have incompatible changes making it non-standard. I say best to just skip flakes since most projects don’t need anything more than pinned input starting point to produce: a package, an overlay, & a module (if relevant).

[neobrain]

(for context, you're replying to the author of an alternative nix input pinning mechanism, which means... they're probably aware of all that and yet they chose their wording like this anyway)

[sshine]

Hahaha, I didn't see.

Hi toastal, I appreciate your work.

[toastal]

ຂອບໃຈເດີ້