I'm glad we didn't yet stabilize because I am skeptical of a number of aspects to Nix. I suspect it's unduly popular because pure eval mode is a food idea, but there is little way to use it outside of flakes.
what do you think of the strategy of stabilizing just the input schema for Nix flakes, which is all that's required for pure evaluation, then stabilizing each component of the output schema separately as those components are called for by specific features of the Nix/NixOS CLI?
That's a neat idea and improvement for sure. I'm pretty pessimistic about the outcome here, and perhaps what you said is a most realistic turn.
There is a larger issue that still irks me: all this stuff is based off Cargo/Cabal/etc., but I think that's fundamentally the wrong model for our purposes. Historically every C package is a snowflake and we do need to package them individually. But as language-based ecosystems take off, we increasingly can auto generate everything we need, and our Nix code is not the bricks but the mortar.
More concretely, the things I do with nix-thunk / Niv today don't really correspond to package boundaries that much, and if they do those repos might not contain any Nix code because I callCabal2nix them. callPackage-style "I am a function of my dependencies" is right, but when those dependency derivations don't align 1-1 with my nix-thunk / niv usage or need extra preprocessing à la cabal2nix, the fundamental concept of flakes breaks down.
I agree with the general orientation in favor of the monorepo and transforming package definitions from repos that don't know/care about Nix, then aggregating them. I think the vision where we use Nix mostly by way of Nix code that has propagated into the source repos of various projects, and we simply use that code directly, probably gets it backwards.
> callPackage-style "I am a function of my dependencies" is right
What did you think of Eelco's presentation at the most recent NixCon where he considers defining packages as NixOS-like modules instead of bare functions?
The TOML one? That might be might be nice, but we should fix the global namespace issues of NixOS modules first. (Sometimes there are scarse global resources to multiplex access too, but that doesn't mean we should only be able to e.g. run only one postgres instance.)
