In reply to @antifuchs:asf.computer
hm, something referenced by my nix config (it's flake-based and I updated inputs) has started using a determinateNix option, and the backtrace I'm getting is extremely unhelpful, even with --show-trace. https://gist.github.com/antifuchs/37c6fd57d62e1867aeff12201377bbfb is that trace from the repl, I can't see anything useful in there, is there a different thing I could do to get more info?

Possibly try a grep -rnFe ‘determinateNix’ or similar in /nix/store

Whatever nix code calling it must exist in the store somewhere.

In reply to @antifuchs:asf.computer
(grep's still running on my store, btw)

In reply to @antifuchs:asf.computer
(grep's still running on my store, btw)

In reply to @vczf:matrix.org
Or **/*.nix as the grep arg should work

Is there any explanation for what nix does when installable's --file/--expr result is a function (return a function or call it)? I (somewhat) figured out the behaviour, couldn't find it documented anywhere and can't figure out if it's intentional and if I can rely on that. Here's what I found, on a nix eval example, but run & build seem to do the same:

• First thing I noticed is nix eval -f '<nixpkgs>' hello returns the derivation (it calls (import <nixpkgs> {}).hello rather than use (import <nixpkgs>).hello. It also processes --arg/--argstr. I feel that the <nixpkgs> behaviour is (somewhat) intentional
• But nix eval -f '<nixpkgs>' returns «lambda @ /nix/store/i88d8nffxs0n79mzgzrpnkiri3yi4isr-source/pkgs/top-level/impure.nix:12:1» rather than toplevel pkgs attrset
• A raw lambda expression behaves similar: nix eval --expr '{...}@args: { inherit args; }' shows «lambda @ «string»:1:1», and nix eval --expr '{...}@args: { inherit args; }' args shows { }
• But if I drop the {...} in function's signature, it stops calling the function: nix eval --expr 'args: { inherit args; }' is «lambda @ «string»:1:1», and nix eval --expr 'args: { inherit args; }' args throws error: the value being indexed in the selection path 'args' at '' should be a set but is a function: «lambda @ «string»:1:1»
• Both nix eval --expr '{ __functor = args: { inherit args; }; }' and nix eval --expr '{ __functor = {...}@args: { inherit args; }; }' never call. Both forms return { __functor = «lambda __functor @ «string»:1:15»; }, with or without args (args attribute path is ignored, it always returns the expr result)
• Adding __functionArgs = {}; to the previous one doesn't change anything: it never calls and ignores the attribute path
• Now I've read up on functors, and both forms above should have failed: evaluating { __functor = args: { inherit args; }; } 23 throws error: attempt to call something which is not a function but a set: { args = { __functor = «lambda __functor @ «string»:1:15»; }; } (missing the "self" first argument), only this form returns 23: { __functor = _self: args: { inherit args; }; } 23
• But if I add the missing arg, nix eval --expr '{ __functor = self: args: { inherit args; }; }' args, I get error: the value being indexed in the selection path 'args' at '' should be a set but is a function: «lambda __functor @ «string»:1:21»
• Without attrpath it doesn't attempt to call: nix eval --expr '{ __functor = self: args: { inherit args; }; }' returns { __functor = «lambda __functor @ «string»:1:15»; }

Now some of this is intentional, some of this is accidental, and some of this is a bug (I'm 92% convinced that calling __functor just once (only with self and not with actual args) is some kind of a bug). None of this seems documented (or I couldn't find it). Can I rely on any of it? How to make it make sense?

In reply to @psentee:matrix.org
(is the answer "The nix CLI is as much of a mess as flakes are, and without flakes you should be using the old CLI"? I like the nix CLI, even without flakes, and so far I've avoided learning the old incantations, I hope to continue using nix, but I'll accept "this CLI is irreparable mess, don't expect any better" as an answer)