 | Nix + dotnet | 130 Members |
| 23 Servers |
| Nix + dotnet | 130 Members |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 9 Jan 2025 | ||
 6pak | so I'm not really sure why it would need this | 16:11:47 |
 GGG | I can't remember well myself honestly | 16:14:41 |
| GGG | @corngood:corngood.com maybe you can shine some light into this one? | 16:15:46 |
| 10 Jan 2025 | ||
 Corngood | I sort of skimmed the above, so sorry if I'm misunderstanding, but you're asking why I'm more familiar with | 13:01:26 |
| GGG | We were more discussing if there's even a need to keep around the apphost binaries in NixOS, since we can just use `makeBinaryWrapper` and make it call `dotnet run` or something similar | 13:06:45 |
| Corngood | You mean get rid of Microsoft.NETCore.App.Host.*? You'd have to fix any projects that try to build self-contained, right? | 13:43:02 |
| GGG | Do we really have a need for self-contained apps in nixpkgs though | 14:21:41 |
| GGG | Feels like unnecessary duplication of runtimes | 14:21:52 |
| GGG | Unless if they're doing AOT | 14:22:03 |
| Corngood | I agree that it's not very nix-like. I just don't think it's practical to avoid it completely. | 14:22:37 |
| GGG | I mean, we can have an escape hatch, but I don't see a reason to provide first class support for it | 14:23:07 |
| Corngood | I don't see what we gain by breaking it. Just removing those packages? We could make them opt-in without breaking it. | 14:24:05 |
| GGG | Not really, it'd just avoid some overhead really | 14:37:04 |
| GGG | Don't know if it is significant enough to justify removing it | 14:40:22 |
| 6pak | imo it should be possible to build self-contained apps with nix, so you can use nix as a build tool and distribute for non-nixos | 14:42:03 |
| 6pak | but none of the packages in nixpkgs should be self contained, yeah | 14:42:13 |
| 6pak | and ideally the dependencies would be used from nix store aswell, not bundled | 14:42:39 |
| 6pak | not removing the package itself | 14:42:58 |
| 6pak | just not outputting an apphost for buildDotnetModule apps in nixpkgs | 14:43:16 |
| 6pak | which is just UseAppHost=false | 14:43:54 |
| 6pak | and instead make our own "apphost" with makeBinaryWrapper that just dotnet execs the dll | 14:44:14 |
| Corngood | The (non-self-contained) apphost is pretty lightweight, so what do we gain from that? | 14:45:46 |
| 6pak | tbf not much, but it's just unnecessary | 14:46:28 |
| 6pak | the question about roslyn-ls is why it needs useDotnetFromEnv | 14:46:53 |
| 6pak | * the question about roslyn-ls was why it needs useDotnetFromEnv | 14:47:03 |
| Corngood | It probably uses DOTNET_ROOT to find the available SDK(s). | 14:48:11 |
| Corngood |
This is on my radar. I've experimented with msbuild options for symlinking outputs, so that they would link back to the package they came from. I had a lot of trouble with it though. | 14:48:34 |
| Corngood | *
This is on my radar. I've experimented with msbuild options for symlinking outputs, so that they would link back to the package they came from. I had a lot of trouble with it though. edit: alternatively we could try to replace them after build, but that's not ideal. | 14:49:15 |
| GGG | Technically, using the source built SDK we could patch nuget to link instead of copy, but I don't like having to maintain a patch set, feels like too much work | 15:01:35 |
| Corngood | It already has UseSymbolicLinksIfPossible etc. I just found that various things break when it's used. | 15:04:10 |