| 13 Oct 2025 |
 MangoIV | is there a workaround for lix to allow mutable locks? Shouldn't passing --impure allow them? | 09:54:30 |
 raitobezarius | but for us to consider it as a change that we should do as well (not a bug), we would need the rationale context | 09:54:31 |
| raitobezarius | the node needs to be locked | 09:54:48 |
| raitobezarius | for a path to be locked, it needs to have its content hash serialized in the flake lock | 09:55:23 |
| raitobezarius | if flakes are now "everything is hermetic except for this little exception here, that little exception there and so on", i'm not sure i understand what is the value of it anymore :) | 09:55:55 |
| MangoIV | so it is a bug in upstream nix, in that it doesn't lock it properly? | 09:56:26 |
| raitobezarius | i don't know if this is a bug upstream or if they decided to change the behavior knowingly | 09:56:46 |
| raitobezarius | * i don't know if this is a bug in cppnix or if they decided to change the behavior knowingly | 09:56:53 |
| MangoIV | yeah, okay, the lock file definitely looks different. | 09:57:07 |
| raitobezarius | btw, fyi, we do not consider cppnix an upstream, our codebases have largely diverged at this point | 09:57:08 |
| raitobezarius | we do try to maintain some sense of compatibility, but we will not do it at the cost of correctness or other objectives we pursue | 09:57:37 |
| raitobezarius | so happy to take an issue if we can realistically do something | 09:57:47 |
| raitobezarius | but i would like to avoid to scavenge the rationale context of what happened there | 09:57:58 |
| MangoIV | since there is no spec, it is kinda hard to see what is upstream and what is not. if nix code stops to be portable across implementation, I think it will be hard to justify words like "reproducible" | 09:58:07 |
| raitobezarius | a spec of flakes you mean? | 09:58:40 |
| raitobezarius | it's an experimental feature | 09:58:45 |
| raitobezarius | flakes have never been reproducible the day they have been marked experimental even if everyone is trying their best to make them stable | 09:59:20 |
| raitobezarius | and it's at odds with "we would like flakes usecases to be fixed" | 09:59:27 |
| MangoIV | I don't know what is correct here. I don't think that paths that are path of the repo need to specify a hash, I think that there's no additional integrity guarantees earned there. | 09:59:30 |
 aloisw | Well it's not impure, right? Because "descendant of directory with locked hash" is still effectively locked. | 10:00:07 |
| raitobezarius | well, at that point, we don't need to copy the repo of the flakes in the store then neither? not sure what flakes provides anymore | 10:00:09 |
| MangoIV | a spec of nix. fwiw I know all this and I'm not saying it is your fault. I just run into these issues and I try to make sense of them. | 10:00:19 |
| raitobezarius | a partial spec of nix do exist ;-) | 10:00:35 |
| raitobezarius | (i'm not saying you're saying it's my fault, dw) | 10:00:44 |
| raitobezarius | isn't it impure for the same reason we do not operate on directory outside of the store? | 10:01:13 |
| MangoIV | I'm not sure what you're getting at here. I am trying to use that feature, I do not want to argue that anyone should use flakes or anything like that :P | 10:01:43 |
| aloisw | Yeah, because the subdirectory is relative to the thing copied to the store (at least if implemented properly). | 10:02:05 |
| raitobezarius | not arguing that flakes should not be used or anything | 10:02:15 |
| raitobezarius | just trying to understand what is the value proposal of flakes today | 10:02:20 |
| raitobezarius | in that case, yeah, that works | 10:02:36 |
