| 18 Dec 2024 |
 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 |
| GGG | At least that's what they claim:
> Package content mismatch: If the same package (id and version) is present with different content across repositories, then NuGet cannot ensure the same package (with the same content hash) gets resolved every time. It also does not warn/error out in such cases. Using the lock file will help you in resolving to the same versions always.
(from: https://devblogs.microsoft.com/nuget/enable-repeatable-package-restores-using-a-lock-file/) | 07:40:00 |
| 6pak | actually nuget uses contentHash, which ignores the signature | 12:01:29 |
| 6pak | which is why, at least in my case the hash was the same for both sources in packages.lock.json | 12:01:53 |
| 6pak | but different in fetchNupkg | 12:01:57 |
| 6pak | * but different in fetchNuGet | 12:02:03 |
| 6pak | from the first glance, that's not what the code does | 12:03:55 |
| 6pak | but turns out I don't have a test case to check | 12:04:11 |
| 6pak | can we do the same in nix somehow? otherwise we wont be able to reuse any kind of hashes from nuget metadata | 12:10:30 |
| GGG | might be possible if we undo the signature in the fetchurl postPatch step | 12:12:28 |
| GGG | only if the hashes match though | 12:12:38 |
| 6pak | 
Download image.png | 12:20:18 |
| 6pak | ;p | 12:20:22 |
| GGG | owell, guess they lied then | 12:20:55 |
| GGG | smh my head | 12:21:03 |
| 6pak | the same can happen randomly without switching the source order if the first one is slow enough | 12:21:03 |
| 6pak | * the same can happen randomly without switching the source order if the first request is slow enough | 12:21:10 |
| 6pak | this is so cursed | 12:21:47 |
| 6pak | PackageReference should have a required Source property, change my mind | 12:23:00 |
| GGG | I don't think it should matter honestly, unless if we're dealing with adversary sources or something | 12:23:53 |
| 6pak | nuget.org is an adversary source | 12:24:27 |
