| 14 Jul 2025 |
 GGG | * like in the nodejs world there's mkYarnDeps and fetchNpmDeps | 18:35:50 |
 Corngood | what do you mean by "its own builder" exactly? like using plain stdenv? | 18:36:03 |
| GGG | I mean as in making nugetDeps be a derivation that the builder then accesses to add the nuget deps to path, instead of a wrapper | 18:36:33 |
| Corngood | what is the builder though? | 18:36:49 |
| GGG | then move the nuget env setup to a hook | 18:36:50 |
| Corngood | oh, you mean just with hooks? like a dotnet-sdk hook? | 18:37:19 |
| GGG | yeah, make a hook to setup the nuget env to use the packages that will be in the path that will be passed with nugetDeps | 18:37:45 |
| Corngood | that's mostly already done for e.g. avalonia | 18:38:03 |
| GGG | instead of what we have with addNugetDeps, so that people have more control over how the nuget deps are set up and patched | 18:38:03 |
| Corngood | configureNuget. there's just currently no buildPhase=dotnetBuildPhase or anything like that | 18:38:35 |
| GGG | oh, my bad, I misunderstood what addNugetDeps did, I misrembered what it did | 18:39:39 |
| Corngood | I'm just not sure how you'd handle fetching without a wrapper around the derivation like addNugetDeps | 18:39:46 |
| GGG | I thought it set up env vars and stuff, but no, it just adds things to buildDeps | 18:39:52 |
| Corngood | yeah, just that and adding fetch-deps plus the derivation override that it uses for that | 18:40:22 |
| GGG | my plan was to make something like nugetDeps = mkNugetRepo ./deps.json; and then a hook would set up the env var for dotnet restore to use | 18:41:05 |
| Corngood | I would really like things to be more composable. like avalonia with multiple npm projects and nuget deps | 18:41:09 |
| GGG | exactly how it is done with npm and yarn | 18:41:22 |
| GGG | because they aren't added to buildDeps afaik | 18:41:45 |
| GGG | I'm not sure if that's right or wrong (I assume wrong most likely), but that'd make it easier to override them out, because otherwise the only choice people would have is to filter out the old buildDeps | 18:42:26 |
| GGG | * I'm not sure if that's right or wrong (I assume wrong most likely), but that'd make it easier to override them out, because otherwise the only choice people would have is to filter out the old buildDeps and add new ones | 18:42:38 |
| Corngood | it's difficult to think about without some concrete examples. I was hoping to get more libraries in nixpkgs and actually use them (like avalonia) | 18:43:44 |
| Corngood | I just haven't been able to put much time into it lately | 18:44:02 |
| GGG | yeah, although I have to admit I'm rather skeptic about people actually building libraries from source and having them in nixpkgs | 18:44:19 |
| GGG | python and node.js folks have tried (and failed) | 18:44:30 |
| Corngood | the whole dotnet ecosystem is very hostile to it | 18:44:34 |
| GGG | that too | 18:44:43 |
| Corngood | even worse than those other languages, because there's no mechanism for distributing or building source | 18:45:22 |
| GGG | it's just that it's rather unrealistic to maintain build scripts for a whole ecosystem, the tools and their whole supply chain | 18:45:27 |
| GGG | it's a nice idea in theory, but in practice it is terribly inefficient and would require way too much effort | 18:45:51 |
| Corngood | I don't think python has failed, has it? I thought it had a pretty thorough repository in nixpkg | 18:46:02 |
