Hey, I’d like to make sure I understand this issue. Even though I prefer using flakes, I appreciate reading and understanding the good-faith arguments from people who aren’t just here to rant!
My understanding is that flakes prevent unpinned inputs in dependencies by evaluating Nix expressions in pure evaluation mode, where fetchTarball fails if a content hash is not specified. We can evaluate non-flake expressions in pure mode by either using the --pure-eval flag, or by enabling the pure-eval Nix setting. But you’re saying there’s something more, or something different required to get a generalized mechanism for reproducible evaluation?
(I read your other post about the definition of “reproducible”. I get the frustration with imprecise use of words. But the evaluation part is reproducible, right? Derivations from pure-eval expressions are bit-by-bit identical, even if store paths aren’t necessarily?)
What might that generalized mechanism look like? Is it something different from pure mode? Or is it some systematic assurance that dependencies will work in pure mode?
I’ve seen a suggestion for pure-eval by default. If pure mode becomes the default assumption then it’s more likely dependencies will work in pure mode, and less likely they’ll stop working randomly in some future update. There would be backward-compatibility pain, but people could use the --no-pure-eval flag where needed.
Or what about some way for an expression to signal that it requires pure mode? Like a special syntax? Or an alternate entrypoint expression convention, like pure-default.nix instead of default.nix? Or some less awful name, like mod.nix?
Flakes were able to avoid the backward compatibility problem by using the alternate entrypoint strategy via flake.nix, sort of creating an alternate ecosystem that is known to be pure. But of course using the flake entrypoint requires adopting all of the flake features. I don’t see how that’s a misdesign, but I do see how it doesn’t do what you want.