| 12 Oct 2025 |
 Charles | this is primarily how i see it used as well | 21:11:07 |
| 13 Oct 2025 |
|  @louis2747:matrix.org left the room. | 00:52:17 |
|  Rcat 🏳️🌈🏳️⚧️ changed their profile picture. | 06:02:28 |
 raitobezarius | I looked and I think I really need to be able to reproduce it on my local system | 09:16:31 |
| raitobezarius | Reading the strace, I'm not sure I see anything that the Nix interpreter is doing wrong | 09:16:39 |
| raitobezarius | It smells more like a nixpkgs level problem | 09:16:48 |
| raitobezarius | If I could build this chorus-nextest derivation, that would be helpful | 09:17:37 |
 MangoIV | flake inputs like inputs.foo.url = "path:./foo" locked with upstream cpp nix throw an error
error: lock file contains mutable lock '{"path":"./foo","type":"path"}' on lix. This cannot be reproduced with upstream cpp nix.
Should I report this as a bug?
| 09:50:06 |
| raitobezarius | not sure, this seems like a mutable lock to me | 09:53:25 |
| MangoIV | and? | 09:53:33 |
| raitobezarius | if cppnix accepts mutable locks now, it probably needs to explain why? | 09:53:51 |
 K900 | IMO cppnix allowing this was a terrible idea | 09:53:57 |
| raitobezarius | i have zero context behind why it was disallowed and now allowed again | 09:54:17 |
| 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 |
