| 13 Oct 2025 |
 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 |
| K900 | I don't see a use case where a subpath is actually meaningfully useful as its own flake input unless you're doing weird subflake stuff or submodules | 10:04:36 |
| K900 | And you shouldn't do those things | 10:04:46 |
| K900 | And I don't even know if this works with submodules | 10:04:56 |
| K900 | I'm pretty sure this is just some lazy trees nonsense that's three steps removed from the actual rationale | 10:05:14 |
| aloisw | To avoid https://git.lix.systems/lix-project/lix/issues/586 I guess. | 10:05:33 |
| MangoIV | our specific use case is a tutorial. there are two sub directories that each are a separate tutorial and the top level flake import the other flakes to allow checking that they still work | 10:05:59 |
| raitobezarius | the change above mentioned do change evaluation semantics of the outputs of flakes though | 10:07:00 |
| raitobezarius | that massively sucks | 10:07:15 |
