| 10 Jan 2025 |
 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 |
| Waldemar Tomme | at runtime | 14:27:02 |
| Emma [it/its] | one sec | 14:27:19 |
| Emma [it/its] | theres a separate thing for that but i need to look it up | 14:27:31 |
| Emma [it/its] | runtimeDeps :) | 14:27:55 |
| Waldemar Tomme | :/ i tried earlier and now as well but it only appends the /lib sub paths to LD_LIBRARY_PATH it seems | 14:29:52 |
| Waldemar Tomme | otherwise I will wrap it but would like it if I can manage it with a single package | 14:31:16 |
