| 24 Oct 2025 |
 emily | the Haskell package set is specifically designed around pinning a specific Stackage LTS | 02:45:09 |
| emily | though they are working on maintaining a parallel Nightly package set AIUI | 02:45:16 |
 Randy Eckenrode | Yeah. I hate it for applications. | 02:45:30 |
| Randy Eckenrode | I want to use the latest hledger because it has some QoL improvements, but I can’t because that’s not what’s in the Stackage LTS. | 02:46:22 |
| emily | you can have specific additional versions of given packages, AIUI | 02:46:41 |
| emily | it just needs adding in the config file | 02:46:45 |
| Randy Eckenrode | I have something hacky that works for a somewhat newer version, but I don’t think I can govnewer than that. | 02:46:49 |
| 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 |
