| 7 Nov 2025 |
 Emma [it/its] | 
Download clipboard.png | 02:44:09 |
 Corngood | It should prefer them but only if they have the version it's looking for | 02:44:12 |
| Emma [it/its] | this is the version the fetch-deps script gives me, fwiw | 02:44:33 |
| Emma [it/its] | (that entire version range was deprecated in favor of 1.0.0-preview.yyyyMMdd-hhmmss+gitrev7 | 02:45:08 |
| Corngood | Didn't the other one you mentioned have a ~ in it? | 02:45:23 |
| Emma [it/its] | * (that entire version range was deprecated in favor of 1.0.0-preview.yyyyMMdd-hhmmss+gitrev7 rather than using github build id) | 02:45:23 |
| Emma [it/its] | it didnt | 02:45:32 |
| Emma [it/its] | 
Download clipboard.png | 02:45:57 |
| Emma [it/its] | but seems that the nuget web ui agrees here that it's actually nix at fault here? | 02:47:10 |
| Emma [it/its] | notably: the URL to that page is https://www.nuget.org/packages/ArcaneLibs/1.0.0-preview.20251104-015635/ (missing the +6fd695c) | 02:47:40 |
| Corngood | If it's working, fetch-deps shouldn't add it at all. Have you tried setting the package and reference version both to just 1.0.0? | 02:55:35 |
| Emma [it/its] | well the issue is that i want to publish the resulting files to nuget | 02:56:26 |
| Emma [it/its] | i'd assume that if i made it 1.0.0, it wouldnt link up correctly in nuget, no? | 02:56:42 |
| Emma [it/its] | why is dotnet-vmr so large 😔 | 03:10:19 |
| Emma [it/its] | 
Download clipboard.png | 03:10:34 |
| Emma [it/its] | i made the mistake of purging my nix store | 03:10:46 |
| Emma [it/its] | well there goes 6min45s of my life just waiting for dotnet-vmr to download | 03:12:07 |
| Corngood | In reply to @emma:rory.gay
i'd assume that if i made it 1.0.0, it wouldnt link up correctly in nuget, no? Yeah just trying to understand what's going on a bit better | 03:12:39 |
| Emma [it/its] | fwiw my current (seemingly working) workaround is uh... | 03:13:04 |
| Emma [it/its] | ArcaneLibs = arcanelibs.packages."${pkgs.stdenv.hostPlatform.system}".ArcaneLibs.overrideAttrs (old: {
__intentionallyOverridingVersion = true;
version = builtins.substring 0 29 old.version; # "1.0.0-preview-20251106-123456";
});
| 03:13:20 |
| Corngood | And with that fetch-deps doesn't add anything? | 03:15:18 |
| Corngood | Is it just because it happens to be newer than anything on nuget.org? | 03:15:50 |
| Emma [it/its] | oh that, no that's unrelated | 03:16:06 |
| Emma [it/its] | dotnet thinks the unlisted package is "newer" due to semver (old format being 1.0.0-preview987654321.abcdefg, new being 1.0.0-preview.20251106-123456+abcdefg, so a lexical string comparison would prefer the former) | 03:18:41 |
| Emma [it/its] | and well, its nuget.org, so theres nothing i can do about that, no way to delete old versions or whatever | 03:20:20 |
| Corngood | I still think the PackageReference version should just be pinned to the one from nix, and if that's not working because of something peculiar with the version number, trying 1.0.0 would prove it. | 03:24:22 |
| Corngood | You want to stop it from looking in nuget.org at all, so either an exact version match or package source mapping. | 03:25:21 |
| Emma [it/its] | that sounds like pain maintenance wise ^^'
i think ill stick to manually removing it from deps.json for the time being? | 03:26:43 |
| Emma [it/its] | in other news, since you maintain dotnet-vmr in nixpkgs: any reason why the build output contains tarballs of the {dotnet,aspnetcore}-runtime packages? i'm not too familiar with building dotnet from source | 03:27:50 |
| Emma [it/its] | (particularly in the lib/Private.SourceBuilt.Artifacts.10.0.100-rc.2.25502.107.linux-x64/ directory) | 03:28:44 |
