Nix + dotnet | 126 Members | |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Dec 2024 | ||
| 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 | |
| we'd also need to guarantee it works with paket and et. all | 22:48:22 | |
| yeah, tools and paket are the ones that come to mind. also some explicit downloads in msbuild, etc | 22:48:25 | |
| and imo it's fair to not handle it in the generic msbuild tooling | 22:48:24 | |
| That context sums it up well -- I don't really like the idea of using the insecure allowance but it may just be what I end up doing. Thanks for the thoughts! | 22:48:40 | |
| That's understandable. Has the upstream project considered this? Providing an LTS build that's not on a supported platform seems odd. | 22:49:38 | |
| upstream seems abandoned from what I saw | 22:49:54 | |
| last release 2 years ago | 22:49:55 | |
| they have some commits but no releases in the interim | 22:50:36 | |