Nix + dotnet | 130 Members | |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Dec 2024 | ||
| I assume you don't want a prerelease version for "Data Preservation Suite" | 22:31:49 | |
| I also don't really understand why it would have built before, but maybe the previous SDK was less strict about checking features or something? | 22:32:25 | |
| likely | 22:32:38 | |
| ref safety got a lot of changes recently | 22:32:48 | |
| but generally you get new warnings/errors when you switch to a newer langversion, not just the compiler | 22:33:11 | |
So I guess you could either set LangVersion globally or patch the specific csproj | 22:33:30 | |
| May end up being a can of worms though | 22:33:44 | |
In reply to @corngood:corngood.comCould be some changes to overload resolution | 22:34:00 | |
| They do those quite often afaik | 22:34:18 | |
Yeah, that's the lts version while the newer versions are WIP. If you look at my Flake, it's split into three versions - lts, prerelease, and git for experimentation in case people want to use specific versions.https://github.com/Whovian9369/aaru-nix-flake/blob/main/flake.nix#L14 | 22:38:48 | |
| GGG, 6pak I am interested in the things you were discussing earlier. I'm not sure where to go with it exactly. Runtime-specific nuget dependencies has been on my mind for a bit, but how do we get there? One way would be to clear $NUGET_PACKAGES between restoring each platform. And then you wouldn't want to bloat the deps file, so you'd also need to group them by runtime somehow. | 22:39:12 | |
| * GGG, 6pak I am interested in the things you were discussing earlier. I'm not sure where to go with it exactly. Runtime-specific nuget dependencies has been on my mind for a bit, but how do we get there? One way would be to clear $NUGET_PACKAGES between restoring each platform. And then you wouldn't want to bloat the deps file, so you'd also need to group them by runtime somehow. ... maybe we should make an issue to discuss that specifically, if one doesn't already exist. | 22:39:30 | |
| imo step one is fetch-deps not restoring at all | 22:39:55 | |
GenerateRestoreGraphFile looked like it had everything we need | 22:40:42 | |
| and it's what the dotnet cli uses for the package subcommand | 22:40:53 | |
| and we have the privilege of dropping ancient dotnet sdk versions, so we can just assume it's there | 22:41:11 | |
In reply to @corngood:corngood.comI think you could just restore to separate folders and combine the results into one JSON file | 22:42:04 | |
| So I think I've hit a bit of a wall with trying to build my
| 22:42:07 | |
| Having a key to specify which platforms you download that package for and then we filter it based on targetPlatform | 22:42:26 | |
In reply to @6pak:matrix.orgDoes it have the hashes for the packages in a format we can consume for the lockfile as well? Never heard of that | 22:42:52 | |
I don't think it's documented, but nothing in msbuild land ever is ;p | 22:43:22 | |
| Yeah, fair enough | 22:43:35 | |
| Nixpkgs has been the only reason I've ever looked into these build specific .net internals | 22:43:54 | |
| it doesn't have hashes annoyingly, even though it could | 22:43:56 | |
| we can always grab it from the nuget server though | 22:44:20 | |
| That would be great, but there are a lot of annoying edge cases to test. | 22:45:35 | |
| the big exception are the nuget msbuild sdks which bypass the regular resolving | 22:47:06 | |
| there are also some packages which download packages outside of the restore target iirc | 22:47:39 | |
| Sorry if I missed the context above, but is the problem just that it's on an EOL SDK? I personally would just allow the insecure dependency and continue to use it as is. | 22:47:40 | |
or that don't use PackageReference and instead do something else | 22:48:10 | |