| 9 Jan 2025 |
 GGG | In reply to @6pak:matrix.org
but does roslyn-ls bundle it's own roslyn binary or uses one from .net sdk I have no idea | 16:05:40 |
 6pak | sdk major/feature-band updates can bring breaking changes | 16:05:55 |
| 6pak | wym by this | 16:06:06 |
| GGG | In reply to @6pak:matrix.org
sdk major/feature-band updates can bring breaking changes I mean, shouldn't TFM take care of that already | 16:06:19 |
| 6pak | I mean build system breaking changes | 16:06:34 |
| GGG | In reply to @6pak:matrix.org
wym by this Because some programs want to use whatever SDK(s) the user has installed on their system | 16:06:45 |
| GGG | Like roslyn-ls | 16:06:57 |
| GGG | Can't remember if there's others | 16:07:04 |
| GGG | But we have a flag for it in `buildDotnetModule` | 16:07:14 |
| 6pak | SDK or runtime | 16:07:52 |
| GGG | In reply to @6pak:matrix.org
SDK or runtime The runtime in the SDK really, since they'll use the SDK themselves as well | 16:08:28 |
| 6pak | it does bundle it's own | 16:11:35 |
| 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 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 |
