| 10 Jan 2025 |
 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 |
| GGG | Weird, why would those break | 15:13:24 |
| GGG | Does it not copy the native libs? | 15:13:32 |
| Corngood | I can't remember exactly. One problem with it is that nuget packages typically have a bunch of versions of things, and you're only linking to one of them, but pulling the whole package into the closure. | 15:14:26 |
| GGG | Oh yeah, the ones that have native libraries package the binaries for all runtimes | 15:18:15 |
| Corngood | Some do. Some have dependent packages like skiasharp.native.linux, but there's also all the TFM variants of assemblies. | 16:04:17 |
| GGG | I don't think there's much we can do without actually reproducing nuget's logic for restoring packages to know what will actually be used | 16:09:35 |
| GGG | And even if we did, one package could use the net8.0 assembly and the other could use net7.0 | 16:10:14 |
