| 18 Dec 2024 |
 6pak | that seems to be happening from what I see | 19:42:34 |
| 6pak | I would use --rebuild but that result in a non descriptive error for impure derivations, for some reason | 19:43:06 |
| 6pak | * I would use --rebuild but that result in a non descriptive error for impure derivations, for some reason (https://github.com/NixOS/nix/issues/9782) | 19:43:31 |
 Corngood |
This is by design, sources are unordered and they are searched by order of the quickest response rather than by order of how they show up in file.
https://github.com/NuGet/Home/issues/3676
| 19:44:26 |
| 6pak | huh | 19:44:51 |
| Corngood | I'm not sure how things have changed since then. But that was why nuget-to-nix had to check all the sources for each package :| | 19:45:04 |
| 6pak | if that's still the case then thats one more reason to always use package mapping | 19:45:38 |
| 6pak | * if that's still the case then thats one more reason to always use package source mapping | 19:45:58 |
| Corngood | You can still end up with multiple sources as options for a package | 19:46:22 |
| 6pak | if that's still the case then I guess what I observed was simply the result of the first source being the first request made | 19:47:10 |
| 6pak | because changing the order did change which package was resolved for me | 19:47:34 |
| Corngood | on the sandbox thing, how do you copy the output file into nixpkgs? that's one nice thing about using firejail for fetch-deps, update scripts, etc. you can easily give it write access to just the nixpkgs repo | 19:49:26 |
| 6pak | outer fetch-deps script is the one invoking the sandboxed build | 19:50:14 |
| Corngood | I guess you still run an outer script outside of the sandbox? | 19:50:18 |
| 6pak | yeah | 19:50:23 |
| 6pak | the protection more is against malicious build scripts in upstream rather than nixpkgs code | 19:50:39 |
| 6pak | * the protection is more against malicious build scripts in upstream rather than nixpkgs code | 19:50:50 |
| Corngood | I wonder if anyone has discussed sandboxing of update scripts anywhere. that's basically the same thing but more widely used | 19:51:16 |
| 6pak | is nixpkgs-update bot even sandboxed? | 19:52:46 |
| Corngood | I'd certainly hope so, but I have no idea where/how it runs. | 19:53:39 |
| Corngood | It's at least not going to be on someone's dev machine | 19:53:57 |
| 6pak | the stupid random order still seems to be a thing https://github.com/NuGet/NuGet.Client/blob/8791d42fb1e7582f9a0b92d1708133c3b138732a/src/NuGet.Core/NuGet.PackageManagement/PackageDownloader.cs#L159 | 20:18:16 |
| 6pak | so looks like really changing order meant that the first one got started first | 20:18:50 |
| 6pak | but thats all | 20:18:53 |
| 6pak | thats so stupid | 20:18:58 |
 GGG | I guess that's why nuget lockfiles should be used when you want determinism | 23:59:11 |
| 19 Dec 2024 |
| 6pak | those don't have the source, just the hash | 06:46:09 |
| 6pak | so a locked restore will just fail randomly if the random order changes | 06:46:41 |
| 6pak | that's assuming the package hash is different in the two sources but I think it can happen with the auto signing stuff? | 06:48:16 |
| GGG | In reply to @6pak:matrix.org
so a locked restore will just fail randomly if the random order changes No, their docs explicitly state that it'll download from the same source based on the hash | 07:36:24 |
