| 18 May 2024 |
 julia | I keep running into FIXME: concerning statement | 04:49:33 |
| julia | screams queryPathInfoUncached (virtual method on a base class) in some implementations returns nullptr for "not there" and others throws an error | 04:56:15 |
| julia | ... some of them even shell out to other functions and catch their invalid path errors | 04:58:35 |
| julia | * ... some of them even shell out to other functions and catch their invalid path errors so as to return nullptr | 04:58:50 |
 Qyriad | yeah. we have inherited a codebase from hell xP | 04:59:35 |
| julia | most seem to be returning nullptr... should I standardise on that? | 04:59:53 |
| Qyriad | absolutely, just carefully make sure the result behavior is still the same, and try to keep changes in a CL closely related | 05:01:50 |
| Qyriad | but we would absolutely love this fixed | 05:01:56 |
| julia | yep planning | 05:02:05 |
| Qyriad | it's minor but every bit helps in this codebase | 05:02:11 |
| julia | it's a protected API so shouldn't have many consumers anyway | 05:02:18 |
| julia | * it's a protected method so shouldn't have many consumers anyway | 05:02:28 |
| julia | it has exactly (1) consumer | 05:06:07 |
| julia | which immediately throws an error anyway | 05:06:32 |
| julia | * which does some more stuff then throws an error anyway | 05:06:45 |
|  madjar joined the room. | 06:49:16 |
 jade_ | In reply to @qyriad:katesiria.org
yeah. we have inherited a codebase from hell xP hellco | 09:38:58 |
|  @draupnir:lix.systemschanged room power levels. | 09:42:48 |
| julia | this is certainly a code base | 09:46:16 |
| julia | me, last hour or so: "what's the point of requireValidPath?"
the code: never uses it
the one doc comment: "If requireValidPath is set to true (the default), the path must be inside a valid store path, otherwise it just needs to be physically present (but not necessarily properly registered)" (for "read a file to a string"). ???? | 09:48:13 |
| julia | * me, last hour or so: "what's the point of requireValidPath?"
the code: never uses it
the one doc comment: "If requireValidPath is set to true (the default), the path must be inside a valid store path, otherwise it just needs to be physically present (but not necessarily properly registered)" (for "read a file to a string"). ????
so there's this one argument passed through n levels of depth through libstore whose entire purpose appears to be... for when the store is borked | 09:48:56 |
 John Ericson | I recall it is used for some derivation thing | 14:12:22 |
| John Ericson | but that might also be store repairing/checking | 14:12:28 |
| John Ericson | In reply to @julia:the-apothecary.club
most seem to be returning nullptr... should I standardise on that? I think the intent is some difference between "know we don't have the path" and "error checking" | 14:16:52 |
 puck | the single usecase is readInvalidDerivation, which is a semantic that i think exists because invalid derivations do end up in the store, but don't get registered properly | 14:20:55 |
| puck | and honestly isn't a great name for what it does (it still requires a valid derivation, just it may not be registered with the store properly; which is, tbh, not something that should be able to happen) | 14:21:48 |
| puck | e.g. the easiest way to make this happen is builtins.toFile "hi.drv" "meow" | 14:22:42 |
| puck | it writes to /nix/store/233k2fcz02xfpi48ildccq1740gh5mcs-hi.drv but also errors out saying error: expected string 'D'; but claims the path is invalid simultaneously | 14:23:46 |
| *  K900 flips the counter | 14:28:07 |
| John Ericson | puck: yeah that reflects my memory | 14:30:45 |
