| 10 Jan 2025 |
 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 |
| GGG | I know we already do, but it's pretty much not used in nixpkgs | 20:39:23 |
| 14 Jan 2025 |
| Corngood | patchcil change: https://github.com/NixOS/nixpkgs/pull/373107 GGG This sounds cool. I'll probably have to wait until I have some downtime to wrap my head around it. I thought others here might be interested. | 13:56:59 |
| GGG | Fair enough, it's not very complex but there are quite a few steps in the process so it's not something that easy to review | 13:58:42 |
| GGG | Even more considering whoever reviews it will need to read and understand the patchcil source as well | 13:58:58 |
 Waldemar Tomme | Hi, quick question (hopefully): I'm building a .NET package with buildDotnetModule and need two cli tools available. I tried buildInputs but this doesn't seem to work. How can I make the tools available to the dotnet tool? | 14:26:03 |
 Emma [it/its] | nativeBuildInputs, iirc? | 14:26:49 |
| Emma [it/its] | or dyou mean at runtime? | 14:26:58 |
| Emma [it/its] | * or do you mean at runtime? | 14:27:02 |
