| 23 Mar 2026 |
 zoë (she/her) | thanks for the clarification and explanation :) | 22:01:00 |
 raitobezarius | In reply to @blokyk:matrix.org
alright i'll leave the issue as is then (without the notes since the debate should probably be had in public and i don't wanna be just paraphrasing someone else's opinion), hopefully it'll garner some more attention from other maintainers/contributors I'd welcome you posting a summary of our convo :-) I am in public transport unfortunately | 22:03:11 |
| zoë (she/her) | aaaaand right after i closed the window aight, i'll do that then ^^ | 22:04:14 |
| raitobezarius | In reply to @blokyk:matrix.org
alright i'll leave the issue as is then (without the notes since the debate should probably be had in public and i don't wanna be just paraphrasing someone else's opinion), hopefully it'll garner some more attention from other maintainers/contributors It will take some time for the maintainers to come to that as we are finishing up with 2.95, taking some time off then kick starting 2.96 (with some priority items we have in mind) | 22:04:21 |
| zoë (she/her) | oh yeah yeah, i imagine 2.95 is keeping everyone busy, especially with lixcon and all the other infrastructure stuff i see passing on the zulip; i'm amazed at everyone on board honestly x) | 22:05:20 |
| raitobezarius | Fortunately, this is the finish line | 22:06:24 |
| raitobezarius | In May, I will hibernate | 22:06:33 |
| zoë (she/her) | is there any specific reason? or is it just taking time-off? | 22:07:03 |
 piegames | Horrors want these use cases put outside of Nix into the top-level commands. My vision is to have tryEval marked as unsafe and explicitly forbidden in any code that produces derivations and should be pure | 22:14:16 |
| zoë (she/her) | i feel like having an outside tool responsible for these sort of things just exerts a behavioral requirement on the nix code that cannot be encapsulated inside of the code, thus, from my point of view, going against purity. from a practical point of view, i do think that in the case of eg hydra it'd make a lot of sense for it to be external, but the idea of just forbidding tryEval completely and requiring external tools to handle any failing scenario seems a little weird.
idk, again it's probably because i don't use nix for ci stuff as much, but if you can't handle any error at all and require an external runner and external tool and everything, then you suddenly nix becomes just the build description language surrounded by bash scripts, which imo is a shame | 22:26:50 |
| raitobezarius | imagining how relaxing will be May compared to these past months makes taking time off even better | 22:30:08 |
| raitobezarius | there's class of errors you simply cannot remediate to | 22:31:10 |
| raitobezarius | what if hash FOD mismatch was a Result<Derivation, FODMismatchError> | 22:31:22 |
| raitobezarius | what value is there into unwrapping the error? | 22:31:28 |
| raitobezarius | what can you meaningfully do with this information? | 22:31:36 |
| raitobezarius | to me, it is the basis to support moving some of the processing logic outside of Nix because those things have inherently impure management | 22:32:10 |
| raitobezarius | in order to leave Nix a pure core | 22:32:16 |
| raitobezarius | incompleteness of a derivation is yet another example and is driven by the lack of instrumented recursive evaluation of attribute sets IMHO, there's no way to perform fancy traversal of these graphs with impure action responses | 22:33:04 |
| raitobezarius | nix-eval-jobs is one instrumented recursive evaluation of attribute sets meant as a porcelain to build more complicated tooling, it theoretically can also do way more than tryEval-based techniques because it has full access into the C++ evaluator primitives and can catch the uncatchable (modulo impl details) | 22:33:56 |
| raitobezarius | yeah, i have been aligned with horrors for a long time on this | 22:35:02 |
| raitobezarius | if we could create the conditions to remove that weird exception handling fragment, that'd be great | 22:36:13 |
| raitobezarius | i don't mind replacing it with Result<T, E> though I think as I said: it's a dream, I don't see that realistic compared to do it right in nix2 | 22:36:52 |
| zoë (she/her) | i do agree with that tbf, and i think the FOD error is a good example of something that doesn't make sense to make catchable; but i don't think all errors should be that way. while in general, things related to bare derivations and building probably aren't gonna be the most useful to catch, the fact you can't run/use any nix expression inside your code without the fear that it might fatally throw is a little frustrating imo. if we did have a Result type it'd obviously be preferable to exceptions, but for the foreseeable future we won't, so i do think it's useful to be able to tell if e.g. some packages fail to eval in nixpkgs, or a property of a object we computed actually throws, etc | 22:46:42 |
| zoë (she/her) | anyway, i think i should maybe stop here, i don't have the same experience and "vision for nix" that most people have here ^^; | 22:47:23 |
| raitobezarius | i agree | 22:47:25 |
| raitobezarius | i think that approaching this problem from different perspective is welcome; but i think: for the exercise to be interesting, it needs to be thorough | 22:48:03 |
| raitobezarius | that is, for each current catchable/uncatchable behavior, providing a rationale for its current status or a rationale to change it | 22:48:23 |
| raitobezarius | i know that i did that when i finished most of the catchable/uncatchable impl in https://snix.dev (which doesn't rely on exceptions but proper Result<T, E> at the Rust level) and i acquired some taste along the fun | 22:48:54 |
| raitobezarius | otherwise, we are kinda condemned into discussing n=1,2,3 examples and i'm not sure this will lead to a satisfying design overall | 22:49:28 |
| raitobezarius | to put it in another way: do not let grand words like "vision for nix" discourage you from finding out your own opinions and communicating them | 22:50:06 |
