| 1 Feb 2026 |
Sofie đłïžââ§ïž (she/her) | fixed it | 13:44:54 |
Sofie đłïžââ§ïž (she/her) | somehow | 13:44:55 |
antifuchs | 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? | 16:17:48 |
lillecarl | How do you guys conveniently dogfood Lix development? If you replace system nix daemon and you break something badly enough and you want to revert for example. I can think of ways but I imagine someone has thought about it more than me đ | 18:26:10 |
hexa | there is always single user mode | 18:36:33 |
lillecarl | hexa: Yeah i guess just calling the old activationscript too. I realize never ever roll backwards | 18:40:38 |
vczf | 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. | 18:47:22 |
antifuchs | yeah, that tracks. and ooof | 18:47:49 |
antifuchs | (grep's still running on my store, btw) | 19:25:16 |
vczf | In reply to @antifuchs:asf.computer (grep's still running on my store, btw) grep -rnFe determinateNix /nix/store/*-source* might work better | 19:38:59 |
vczf | Not at my computer right now though | 19:39:13 |
vczf | In reply to @antifuchs:asf.computer (grep's still running on my store, btw) * grep -rnFe determinateNix /nix/store/-source/**.nix` might work better | 19:41:04 |
antifuchs | yeah, I probably could do something smarter with find/xargs there | 19:41:30 |
antifuchs | find /nix/store -type f -name \*.nix -print0 | xargs -0 grep -l determinateNix so I don't run into argv limits | 19:42:20 |
vczf | Or **/*.nix as the grep arg should work | 19:43:39 |
K900 | rg -t nix determinateNix ez | 19:45:02 |
antifuchs | In reply to @vczf:matrix.org Or **/*.nix as the grep arg should work Not in my shell, no. But anyways Iâm off to walk the dog, should be done by then | 19:47:26 |
antifuchs | (Also I donât trust rgâs file selection mechanisms at all, unless Iâm in a git repo. Been burned too many times by that) | 19:47:57 |
vczf | Oh lol ripgrep is almost 10 years old and I still havenât gotten around to trying it | 19:48:27 |
0x4fbb09 it/its âŻâÎÎ | the automatic exclusions? | 19:48:35 |
toonn | Start today! | 19:48:41 |
0x4fbb09 it/its âŻâÎÎ | yeah, rg -uuu is the way to specify "search absolutely everything" | 19:49:14 |
antifuchs | I felt like I could trust it once, then the cli changed and I havenât trusted it since. Maybe in 10 years I will use that again, but for now? Nah | 20:18:59 |
antifuchs | Itâs great in git repos tho! | 20:19:44 |
Sofie đłïžââ§ïž (she/her) | rip grep all đ | 20:24:33 |
| zimward changed their display name from zimward @fosdem to zimward. | 20:36:21 |
rosssmyth | Main thing ripgrep messes up on in my experience is with .gitignore because it uses a parser that is not very good | 22:57:43 |
| 2 Feb 2026 |
antifuchs | update, it's virby, a linux-in-a-rosetta-vm builder for darwin. oh well. | 01:34:24 |
| holly [nexus] đłïžââ§ïž joined the room. | 07:27:17 |
Psentee | 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?
| 11:39:55 |