| 24 Oct 2025 |
 emily | talk to the Haskell maintainers about it? | 02:46:50 |
| emily | it'll be a lot easier to maintain in Nixpkgs than externally | 02:46:59 |
| emily | they support multiple versions of specific packages within the set | 02:47:10 |
 Randy Eckenrode | https://github.com/NixOS/nixpkgs/issues/190542 | 02:48:03 |
| Randy Eckenrode | The newer version of hledger in the set doesn’t build. It seems to be a recurring problem. | 02:48:47 |
| emily | if you sign up as a maintainer you get automatic pings when haskell-updates breaks it | 02:49:31 |
| emily | that's something they have somewhat better tooling for than us | 02:49:40 |
| emily | general-us :) | 02:49:48 |
| emily | https://github.com/NixOS/nixpkgs/pull/453350 | 02:50:03 |
| Randy Eckenrode | Though it seems that Haskell may be using unversioned arguments with different releases pinning to different versions. | 02:50:04 |
| emily | looks like it was also done. | 02:50:08 |
| Randy Eckenrode | Now I need to update my flake to get it. I have a bunch of stuff I can simplify if I could use the table format with complex conditions. | 02:51:18 |
| Randy Eckenrode | So, somewhat related, if I want to be ready for allowing scopes in by-name, what’s the best approach to use? I’m thinking of a swiftPackages scope. | 02:54:16 |
| emily | I think just do whatever you were doing pretty much | 02:56:36 |
| emily | we are already having to think about how to port the existing scopes | 02:56:45 |
| emily | which do some pretty gnarly things | 02:56:53 |
| emily | if you can try to avoid putting random things that aren't packages in the scope that's nice | 02:57:07 |
| emily | and use makeScopeWithSplicing | 02:57:31 |
| Randy Eckenrode | That’s pretty much what I was doing. The plan was to rely on the scope to handle cross, so I just need to provide swiftPackages.stdlib. | 03:04:07 |
| Randy Eckenrode | For example. | 03:04:12 |
| Randy Eckenrode | So don’t put functions in the scope? Can they be in packages? While I want to move away from swiftpm2nix, I plan to keep it for compatibility. | 03:05:21 |
| emily | generic builder functions are surely something we'll have to handle in some form or another | 03:06:17 |
| emily | and passthru functions surely can't cause any more issues than they already do (you can put 'em in by-name already) | 03:06:31 |
| Randy Eckenrode | It has some boilerplate stuff it exports IIRC. | 03:06:53 |
| emily | realistically each scope will need to be manually looked at | 03:07:09 |
| emily | and the existing ones have pretty gnarly stuff already | 03:07:22 |
| emily | I wouldn't anticipate major issues unless yo utry to do super magic things | 03:07:40 |
| emily | it's mostly just been a question of how we need to extend by-name and what that mechanism should look like | 03:07:59 |
 samasaur | i think you may have | 05:23:09 |
| samasaur | patching this function down to just set(${out_var} "-framework ${framework_name}" PARENT_SCOPE) makes everything build | 05:23:51 |
