shellFor doesn't work with hspec-discover test-suites

[rvl]

If the cabal package has a test-suite with build-tools: hspec-discover, then cabal will not work in the development shell:

# cabal new-configure --enable-tests
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: project-0.1.0.0 (user goal)
[__1] rejecting: project:!test (constraint from config file, command line
flag, or user target requires opposite flag selection)
[__1] trying: project:*test
[__2] next goal: project:hspec-discover:exe.hspec-discover (dependency of
project *test)
[__2] rejecting:
project:hspec-discover:exe.hspec-discover-2.7.1/installed-EHO... (does not
contain executable 'hspec-discover', which is required by project *test)
[__2] fail (backjumping, conflict set: project,
project:hspec-discover:exe.hspec-discover, project:test)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: project, project:test,
project:hspec-discover:exe.hspec-discover   

The tests component builds fine, because hspec-discover is provided in the PATH.

But I think the build-tools which are haskell packages need to be added into the package database for shells.

A disabled test case for this is added in #181.

[purefn]

I have just run into this. Is there any known workaround?

[purefn]

I tried adding hspec-discover to the additional argument for shellFor, but without any luck.

with (import ./nix);

hsPkgs.shellFor {
  buildInputs = with pkgs; [
    cabal-install
  ];
  additional = ps: [ ps.hspec-discover ];
  exactDeps = true;
}

[purefn]

I've done a little more digging and it looks like cabal is trying to figure out how to resolve the exe component of hspec-discover. For libraries, it can do that via the package db. But how can we tell it resolve a Haskell exe? They don't appear in the package db. Is there another way?

[purefn]

Hmm I've just noticed that the hspec-discover executable is available on the PATH in the shell environment. So if we could just tell cabal-install not to even bother trying to build these executables that would be enough.

[rvl]

Yeah exactly right @purefn - the progam is available on the PATH but Cabal thinks the exe component is not installed. I do not know how to fix this.

The workaround is to set exactDeps = false.

[purefn]

@rvl I tried that, but ran into issues with cabal coming up with its own plan. It wanted to use a different version of classy-prelude than it was supposed to. I'm not sure how to stop it from doing that if exactDeps = false.

[rvl]

Yeah that is the downside. I found in my case that cabal's own plan was fairly similar to the Haskell.nix package set, and it only needed to download and build a handful of packages.

[codygman]

I'm also affected by this.

[tscholak]

count me in, too. I've set exactDeps to true, and I'd like to keep it this way.

[LaurynasPukenas]

I'm also affected by this.
As per other comments, setting exactDeps = false resolved the issue, but I wish I could set it to back to true

[rimmington]

Worked around this by removing hspec-discover from the .cabal file and specifying an additional module:

let pkgSet = pkgs.haskell-nix.mkStackPkgSet {
  inherit stack-pkgs;
  pkg-def-extras = [];
  modules = [
    {
      # https://github.com/input-output-hk/haskell.nix/issues/231
      packages.$pkg.components.tests.$pkg-tests.build-tools = [
        pkgSet.config.hsPkgs.hspec-discover
      ];
    }
  ];
};
in pkgSet.config.hsPkgs

Tests run fine in nix-shell (cabal test) and nix-build (nix-build $pkg.checks), but since Cabal no longer knows about the dependency I suspect other use cases may break.

[414owen]

We're also affected by this.

Our workaround: remove hspec-discover

[codygman]

It's not possible to convince anyone not already sold on Nix to get rid of hspec-discover, is there any other solution here besides exactDeps = false?

exact-deps = false just invites the "I thought nix was for reproducibility" criticism, which honestly is entirely valid.

For my $work codebase, proper handling of build-tools seems to be the last missing piece for being able to transparently move from using docker to using haskell.nix and flakes with nix develop. I'm invested in figuring out how to help move this forward, but haskell.nix is pretty large.

[L-as]

https://github.com/Plutonomicon/plutarch-plutus/blob/master/flake.nix#L140

[codygman]

The latest state of this issue seems to be: #1367 (comment)

[michaelpj]

I don't agree: #839 (comment)

[michaelpj]

The more general issue is here: #839