 | 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 | In general, I'd recommend doing the smallest amount of changes from increasing complexity | 21:34:09 |
| raitobezarius | In this case, I'd recommend adding an error that has the same catch ability property as the one in drvStrict and from there we can pile up semantic changes with careful justification | 21:34:52 |
| raitobezarius | If we restrict the changes to these atomic pieces, it's E/easy, I don't know if changing catch ability is not kind of Context/Maintainers because of some risky semantic changes we do not like in general | 21:35:48 |
| raitobezarius | For the record, I am not sure I understand why we would make this error catchable, having an empty output list is always a fatal error, if your output list is conditional and dies when a platform is not supported or some data is unavailable, you should throw before the derivation thunk in its fully resolved form is resolved | 21:38:17 |
| raitobezarius | So contrary to the opinions expressed, I'd keep a fatal error because it reports more useful information to the end users rather than waiting an access to the derivation to discover that the outputs list is empty for that specific instantiation of context | 21:39:10 |
 zoë (she/her) |
| 21:43:38 |
| zoë (she/her) | *
i think i'm missing a step here, because i don't understand what the fatality of the error has to do with when it is reported. wouldn't a non-fatal and fatal error have the same laziness (assuming they're implemented by just changing | 21:43:43 |
| zoë (she/her) | *
| 21:43:46 |
| zoë (she/her) | *
i think i'm missing a step here, because i don't understand what the fatality of the error has to do with when it is reported. wouldn't a non-fatal and fatal error have the same laziness (assuming they're implemented by just changing | 21:43:49 |
| raitobezarius | A non fatal error will be silenced during large Nix evals or attribute names recursive enumeration by tryEval | 21:45:29 |
| 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 |