| 10 Jan 2025 |
 Corngood | * then you're using packages from nuget.org or something. maybe if you had fetch-deps use the master avalonia package? | 17:06:50 |
 6pak | but different outputs would solve it with no negatives right? (assuming they work how I think they do) | 17:06:50 |
| 6pak | oh you mean a list in consuming projects? | 17:07:27 |
| Corngood | it wouldn't be different from having separate derivations | 17:07:29 |
| 6pak | you would build avalonia twice | 17:07:44 |
| 6pak | * you would build avalonia once | 17:07:54 |
| Corngood | oh I see. I guess it would save storing the monolithic output, but that wouldn't be used directly by anything | 17:08:45 |
| 6pak | unless with the copy approach you would make the monolith uncacheable, which also works I guess? | 17:08:52 |
| 6pak | but it feels like the outputs thing was literally designed for this | 17:09:16 |
| Corngood | I pasted the nuspec above to show the dependencies. If they were all separate, you'd have to do buildInputs = [ avalonia avalonia-remote-protocol ], etc. | 17:09:52 |
| Corngood | Unless we teach the builder to understand those dependencies and propagate them. | 17:10:13 |
| 6pak | can't you just use propagatedBuildInputs? | 17:10:28 |
| Corngood | yeah, but you need to get the dependencies from the nuspec:
<group targetFramework="net6.0">
<dependency id="Avalonia.Remote.Protocol" version="11.0.11" exclude="Build,Analyzers" />
| 17:10:56 |
| Corngood | and they depend on target frameworks, etc | 17:11:12 |
| 6pak | you could get it at avalonia's fetch-deps stage | 17:11:28 |
| 6pak | nuget restore includes figuring out projectreferences metadata | 17:11:44 |
| Corngood | it's the output of avalonia, so I think you'd have to do it in the dependent project's fetch phase? | 17:11:59 |
| Corngood | oh wait, I see what you mean | 17:12:10 |
| Corngood | yeah, maybe fetch-deps could determine something about the output packages. but still you have dependencies that are dependent on TFM. so a dependent project on net6.0 and netstandard2.0 might have different dependencies. you could be conservative and link all of them I guess | 17:12:58 |
| 6pak | this would be bad though | 17:13:02 |
| Corngood | I didn't completely give up on it. this is just where it started to get hairy and I was trying to use the nuget sdk to figure out dependencies etc | 17:13:43 |
| 6pak | tbh listing it out manually might not be that bad | 17:14:11 |
| Corngood | yeah, maybe not. avalonia is probably about as complex as it gets | 17:14:31 |
| 6pak | yeah | 17:14:37 |
| Corngood | I want to get back to it at some point and make an up to date source build of avalonia that's actually used by things in nixpkgs | 17:14:52 |
| 6pak | and you can just have a meta package for avalonia in nixpkgs that includes all you need | 17:14:53 |
| 6pak | with how shady avalonia can be, it would be nice tbh | 17:15:22 |
| Corngood | I gotta run, but I'll check in later | 17:15:29 |
 GGG | I mean, we could just start with avalonia as a monolithic package initially | 20:38:31 |
| GGG | Better have something than nothing honestly | 20:38:37 |
