| 9 Jan 2025 |
 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 roslyn-ls would need the ability to run against different runtimes/SDKs?
I'm more familiar with omnisharp-roslyn, but I imagine they are similar. It's important that it's able to use the same compiler (roslyn) used to build whatever project it's loading. It might not be important that it runs on a particular runtime, but I guess it ensures that the runtime can load the compiler.
| 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 |
and ideally the dependencies would be used from nix store aswell, not bundled
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 | *
and ideally the dependencies would be used from nix store aswell, not bundled
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 |
| GGG | Huh | 15:13:16 |
