| 17 Dec 2024 |
 GGG | It'd also make it quite a pain to package anything | 22:05:56 |
| GGG | If you had to make a derivation for every single csproj | 22:06:14 |
| GGG | In reply to @6pak:matrix.org
where in dotnet you tend to have multiple projects in solutions that have different kind of outputs I don't see how this prevents us from having a single hostSystem really... Also, you gotta consider cross builds too | 22:06:57 |
| GGG | Maybe it's because I'm out of the loop on the conversation you had with @corngood:corngood.com but I think having per hostPlatform deps should work | 22:08:16 |
| GGG | We just need to switch up how the JSON file is organized but sounds doable | 22:08:33 |
 6pak | I mean yes it would work but it's just so hacky | 22:09:08 |
| GGG | Is it? I think other languages that don't compile to native should have pretty much the same scheme | 22:09:38 |
| GGG | I know the npm folks have pretty much the same scheme, download deps for all targets | 22:09:53 |
| GGG | Then they just don't use said dep if not on that target | 22:10:10 |
| GGG | Idk how it's in java land, but should be similar | 22:10:31 |
| 6pak | I don't think npm even has a way to filter deps though? | 22:10:39 |
| GGG | It doesn't, and in .NET most projects don't bother to filter deps by runtime id either | 22:11:00 |
| GGG | So if we want that it's something we'd have to do manually or have said benefit for the small amount of projects that do | 22:11:28 |
| GGG | I'm unsure how many savings that would actually bring us | 22:11:39 |
| 6pak | every project with an apphost does | 22:11:40 |
| GGG | I mean, the packages with native libs do, but other than those, idk | 22:12:14 |
| 6pak | seeing how cross compilation was completely broken until recently, no one cares tbf | 22:12:28 |
| 6pak | my issue with buildDotnetModule is that you have things like packNupkg and selfContainedBuild top level and they apply to all projects | 22:15:34 |
| 6pak | so the model of a nix derivation and .net project seem disconnected | 22:15:50 |
| GGG | How would you suggest it work though | 22:16:17 |
 Corngood | I would like to move away from buildDotnetModule personally, and use something based on dotnet-sdk hooks. The avalonia package was a bit of a test case for this. | 22:16:25 |
| 6pak | you can't easily linux-x64 publish one project and nuget pack another from one solution | 22:16:31 |
| 6pak | because from one side buildDotnetModule properties are global for all projects | 22:16:43 |
| 6pak | and from another you can't easily break up subprojects into multiple nix derivations because of how msbuild projectreferences work | 22:16:59 |
| GGG | Yeah, but that's a non-objective really, most `buildX` that I know of don't let you have multiple outputs | 22:17:04 |
| 6pak | I see a projectReferences property in buildDotnetModule which sounds nice in theory, but in practice msbuild treats projectreferences very differently to packagereferences | 22:17:25 |
| 6pak | which is a pet peeve of mine | 22:17:30 |
| 6pak | but ^ | 22:18:32 |
| 6pak | if we can't nicely break up subprojects into nix derivation because of how msbuild works | 22:18:43 |
| 6pak | imo exposing procedural bash helpers instead is the way to go | 22:18:56 |
