| 30 Nov 2024 |
 vcunat | If there's something important. Or wait a bit, as it looks like in just a few days there will be a full staging -> staging-next. | 16:26:36 |
| vcunat | * Yes, if there's something urgent. Or wait a bit, as it looks like in just a few days there will be a full staging -> staging-next. | 16:26:52 |
| vcunat | But you can't really expect that one merging to master sooner than in about two weeks from now. | 16:27:24 |
 sterni (he/him) | yeah, that's not ideal, but fine; I don't have a lot of time anyways at the moment | 16:30:29 |
| sterni (he/him) | maralorn: anything you want to send to staging quick? | 17:21:54 |
| sterni (he/him) | the thing is that a lot of stuff could actually be sent to master as well on haskell-updates 🤔 | 17:22:14 |
| vcunat | In reply to @sternenseemann:systemli.org
vcunat: that staging-next wasn't branched off from staging right? Correct, it was not. (I forgot this part somehow.) | 17:41:32 |
 maralorn | In reply to @sternenseemann:systemli.org
maralorn: anything you want to send to staging quick? Nothing comes to mind. | 17:52:12 |
| maralorn | We just need to get back into an update rhythm. | 17:52:27 |
| vcunat | This won't even rebuild the default ghc if I look right (on x86_64-linux at least). | 17:53:07 |
| sterni (he/him) | yeah staging-next looks very tame actually, the stuff that is well tested doesn't cause a lot of rebuilds anyways so we can probably easily pick it: https://github.com/NixOS/nixpkgs/pull/360499 | 17:54:07 |
| sterni (he/him) | need to double check the linux rebuild count though that seems wrong | 17:54:16 |
| vcunat | I'm doing that already. | 17:54:46 |
| vcunat | 11 x86_64-darwin
11 x86_64-linux
| 17:55:05 |
| vcunat | That... sounds like it could go to master directly 😆 | 17:55:49 |
| vcunat | Unless the script excludes haskellPackages by some mistake. | 17:56:19 |
| vcunat | No, I reran with --print and it looks OK. | 18:28:01 |
| sterni (he/him) | Yeah, there are just some rebuilds in variants of the haskell package set, but I think those jobs are only built by haskell-updates | 18:42:45 |
 Patrick Steele | In my dev shell, I can run
cabal build test:tests
to compile an executable that runs my tests. Is there an easy way to get a Nix derivation to build this, without manually wrapping cabal-the-command-line-program?
(I know tests are run when I compile the associated program with Nix; I'm interested in compiling the test executable to run in CI, and I don't want to depend on cabal-install because it likes to look at Hackage)
| 20:05:20 |
| Patrick Steele | In reply to @sternenseemann:systemli.org
Patrick Steele: overrides defaults to haskell.packageOverrides by default, so changing that attribute applies something globally. Any changes to either of course need to be written in a way that preserve previous overrides via lib.composeExtensions if you care about that. Thank you. | 20:07:02 |
| Patrick Steele | pkgs.haskell.lib.setBuildTarget seems to come really close to what I want | 20:16:36 |
| sterni (he/him) | you can fiddle around it probably. The problem is iirc that Cabal refuses to install executables that are test-suites, so you have to write a custom installPhase | 20:18:51 |
| sterni (he/him) | consequently there's not really proper support for this thing at the moment | 20:19:10 |
| Patrick Steele | thanks for confirming my growing suspicion; what gets tossed in result/ when I build haskell.lib.setBuildTarget whatever "test:tests" looks like only the library build, not anything I can run | 20:20:15 |
 alexfmpe | You can make cabal not look at hackage FWIW | 20:22:13 |
| alexfmpe | https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-active-repositories | 20:22:48 |
| Patrick Steele | ya, my current workaround for the hackage issue is --config-file /dev/null, but if you have a better solution --- reading, thanks | 20:23:00 |
| alexfmpe | (still need to give its a pkg db via nix) | 20:23:04 |
| Patrick Steele | actually I have --config-file /dev/null --active-repositories=:none and I haven't tested removing the second flag | 20:23:43 |
| alexfmpe | Hmm I dunno if you can pass this via CLI | 20:24:47 |
