| 30 Nov 2024 |
 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 |
| Patrick Steele | I mean, this is working for me, somehow. (And was failing without it.)
Annoyingly I can't replicate what Github Actions are doing locally, so I can't even reproduce this locally | 20:25:28 |
| Patrick Steele | test =
let
shell = self.devShells.${system}.default;
in
pkgs.writeShellApplication {
name = "test";
runtimeInputs = [ pkgs.cabal-install ] ++ shell.nativeBuildInputs;
text = ''
cabal --config-file /dev/null --active-repositories=:none test --test-show-details=always "$@"
'';
};
is how I'm coercing tests to run in CI
| 20:26:04 |
| alexfmpe | Huh why do you want to build with nix but not run with nix? | 20:28:16 |
| Patrick Steele | I do want to run with Nix, I'm not claiming this is idiomatic. My initial question is me trying to figure out how to get Nix to just run the tests directly | 20:28:46 |
| alexfmpe | why not "nix-shell --run 'cabal test all' | 20:28:46 |
| alexfmpe | * why not "nix-shell --run 'cabal test all'" | 20:28:56 |
| alexfmpe | * why not "nix-shell --run 'cabal test all'" | 20:29:05 |
| Patrick Steele | Would that have different behavior? In my mind those are awfully close | 20:29:21 |
| alexfmpe | This is what I do if I want to CI the dev shell itself | 20:29:44 |
| Patrick Steele | I'll give it a try | 20:30:05 |
| alexfmpe | Otherwise I just let the nix derivation do everything | 20:30:15 |
| alexfmpe | You seem to be using flakes though. I think that's 'nix develop' or something rather than nix-shell | 20:31:09 |
| alexfmpe | In reply to @prsteele:matrix.org
Would that have different behavior? In my mind those are awfully close This would build your project (not the deps) outside of nix | 20:32:23 |
| Patrick Steele | I see | 20:42:38 |
| Patrick Steele | thank you | 20:42:46 |
