 | Lix Development | 424 Members |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 140 Servers |
| Lix Development | 424 Members |
| (Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel. | 140 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Mar 2026 | ||
 raitobezarius | A fatal error won't | 21:45:36 |
 zoë (she/her) | yeah but that's only if using tryEval, which imo is rarely seen in the average user's code | 21:46:15 |
| raitobezarius | It's not a laziness issue more of a: there's a culture of using tryEval to perform certain CI operations where fatal or non fatal have different outcomes | 21:46:17 |
| zoë (she/her) | * yeah but that's only if using tryEval, which ime is rarely seen in the average user's code | 21:46:22 |
| zoë (she/her) | hmmm, i'll admit i don't have as much experience on the full ci side :/ | 21:46:46 |
| zoë (she/her) | * hmmm, i'll admit i don't have as much experience on the ci side :/ | 21:46:59 |
| raitobezarius | You can grep tryEval in nixpkgs | 21:47:16 |
| raitobezarius | You will see the use sites | 21:47:21 |
| raitobezarius | The fatal or non fatal discussion is rooted in how tryEval is actually used in practice and what is it for IMHO | 21:47:42 |
| raitobezarius | If tryEval didn't exist, might consider all non fatal errors fatal because you cannot recover computation in any fashion then | 21:48:01 |
| raitobezarius | My vision is that tryEval exist to allow partial evaluation of the package set under different contexts (architectures, libc, etc.) and allowing a derivation definition to be partial if it doesn't support an architecture or a libc or something without compromising the operation "what are the theoretical possible packages here?" and variations of this introspection idea | 21:50:26 |
| raitobezarius | In this framework, an empty output list would make sense if the output list names depend on this data, I can think of some cursed things to do there but none of that occur naturally and I don't see any advantage of starting doing that at all | 21:51:25 |
| zoë (she/her) | for fun/the record, here's the occurences of most of them are tests, but there are still some uses outside of that, which from the few glances i've had are custom option types doing weird stuff | 21:54:09 |
| zoë (she/her) | i understand your point of view though, i guess it's a little more grounded in what nix is currently used for rather than my | 21:55:21 |
| raitobezarius | In my abstract PoV, Nix should have had a Result type | 21:56:31 |
| raitobezarius | That abstract Nix is only a fleeting dream alas | 21:56:40 |
| zoë (she/her) | with all that said, i still do have a question: should it be tagged E/Easy (with the notes from this discussion) and left to be drive-by contributed? it's not very urgent, and though it doesn't go into the c++ part of the codebase like most other changes will require, i still think it can be a good exercise, especially if combined with some tests | 21:57:09 |
| raitobezarius | Yes if it doesn't try to change catch ability | 21:57:43 |
| raitobezarius | Changing catch ability is a debate that needs to be done, I only provided my view so far | 21:58:03 |
| zoë (she/her) | 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 | 22:00:51 |
| zoë (she/her) | thanks for the clarification and explanation :) | 22:01:00 |
| raitobezarius | In reply to @blokyk:matrix.orgI'd welcome you posting a summary of our convo :-) I am in public transport unfortunately | 22:03:11 |
| zoë (she/her) | | 22:04:14 |
| raitobezarius | In reply to @blokyk:matrix.orgIt 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 |