| 13 Oct 2025 |
 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 |
 K900 | This is a special case for paths relative and fully contained in flake root | 10:02:48 |
| K900 | I still have no idea why | 10:02:55 |
| MangoIV | oh, i do not wish to partake in that discussion, I just want to explain to myself why I cannot use this nix code with lix that I can use with upstream nix. | 10:02:56 |
| raitobezarius | it's helpful for us to decide what to do | 10:03:16 |
| raitobezarius | it's not a debate :) | 10:03:18 |
| MangoIV | probably usability issues? you don't have to update the lock file every time something in the repo changes | 10:03:23 |
| MangoIV | that is a really good usability feature, fwiw | 10:03:40 |
| K900 | The short answer is we didn't backport https://github.com/NixOS/nix/pull/10089 | 10:03:43 |
| raitobezarius | it makes sense to me to say that relative paths to a locked node are locked | 10:03:43 |
