 | Nix + dotnet | 129 Members |
| 23 Servers |
| Nix + dotnet | 129 Members |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Jan 2025 | ||
 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 |
| 6pak | could you have avalonia derivation output all those nuget packages in different outputs and then have dummy derivations like Avalonia.X11 that just link to one of the avalonia outputs? | 17:02:14 |
| 6pak | * could you have avalonia derivation output all those nuget packages in different outputs and then have dummy derivations like Avalonia.X11 that just links to one of the avalonia outputs? | 17:02:29 |
| 6pak | (I'm not really sure how nix derivation outputs thing works tbf) | 17:02:47 |
| Corngood | Yeah, I started building something like that, but instead of separate outputs I made separate derivations and pulled in parts of the monolithic one. You do need to define the list of packages at eval time, which is annoying. | 17:03:48 |
| 6pak |
pull as in link or copy? | 17:04:23 |
| Corngood | copy | 17:04:31 |
| Corngood | Where I got stuck is that I wanted the packages to depend on each other properly. Currently you can reference avalonia and get everything, but I didn't want dependent projects to have to list a bunch of transient dependencies in buildInputs | 17:04:53 |
| 6pak | because link would mean you still have everything in closure, copy means you have the same thing twice in store/cache | 17:04:58 |
| Corngood | right, I thought it would be better to favour build closure size for dependent projects | 17:05:49 |
| 6pak |
can't you do it at fetch-deps stage? | 17:05:55 |