 | Nix + dotnet | 128 Members |
| 24 Servers |
| Nix + dotnet | 128 Members |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Jan 2025 | ||
 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 |
| 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 |
| Corngood | Yeah, and both could be used in a dependent package. Nuget packages are not really designed to be runtime dependencies. It still might be worth doing though, even if it's just to reduce the size of the leaf packages. | 16:53:22 |
| 6pak |
could we use multiple derivation outputs for this? | 16:53:59 |
| 6pak | also whats the cost of adding more derivation/store objects in nixpkgs | 16:55:10 |
| 6pak | I mean eval time and storage wise | 16:55:14 |
| 6pak | it feels like splitting things up is discouraged | 16:55:48 |
| Corngood |
potentially, but you'd need to know at eval time how to split it up, so it would have to be done fetch-deps or something | 16:56:37 |
| Corngood | I also want to end up with a good experience for source-built packages, and there's another layer of complexity there. Take 'avalonia' for example. That's one repository with one build process, but it results in a whole bunch of nuget packages. These all have dependencies between each other, and only some will be used by a dependent project. So for one nixpkgs package (avalonia) you currently have one output that contains all the nuget packages, and each one of those potentially contains multiple sets of assemblies for different target frameworks. | 16:59:11 |
| Corngood | * I also want to end up with a good experience for source-built packages, and there's another layer of complexity there. Take 'avalonia' for example. That's one repository with one build process, but it results in a whole bunch of nuget packages. These all have dependencies between each other, and only some will be used by a dependent project. So for one nixpkgs package (avalonia) you currently have one output that contains all the nuget packages, and each one of those potentially contains multiple sets of assemblies for different target frameworks (this might not be the case for avalonia if it's all built for a single TFM). | 16:59:48 |
| Corngood | Actually here's an example of part of the output of that package: | 17:00:33 |
| Corngood | so you have four assemblies there, and a dependent project might only need one of them | 17:01:46 |