Open sol opened 9 years ago
Thanks 😄 I'll see what I can do. If you figure it out please submit a pull request 😊
@shell could we just not look at the cabal file at all and use cabal exec
for sandbox support?
^ @schell sorry, wrong mention...
@sol There's already some other tickets regarding sandbox support, so dropping the current implementation would affect that work as well. I'm guessing that the easiest way to fix this is to add support for test dependencies by parsing the cabal file. @maximkulkin - do you have any input?
@schell Do you have any other input on where newcomers to hdevtools' source can start looking to implement this functionality?
@jsantos17 - you can take a look at the work that @maximkulkin has done with regard to cabal sandboxes (https://github.com/schell/hdevtools/commits/master @maximkulkin's changes from Feb 15th 2014 - March 16th 2014). My guess is that hdevtools is only looking at the executable named after the cabal project and not other executables as well.
I guess the problem is in this line https://github.com/schell/hdevtools/blob/master/src/Cabal.hs#L119: you need to pass --enable-tests option in cfgFlags (along with any other standard or custom options that you have in *.cabal file).
This patch should fix that: https://github.com/maximkulkin/hdevtools/commit/4806bd9d152261bf3c71673af2647bd75288040f
Just pass extra argument to hdevtools:
hdevtools check --cabalopts "--enable-tests" MyFile.hs
There still could be situations when this approach won't work. Currently hdevtools merges all options from all enabled artefacts in Cabal file. It could possible be situation when two artefacts have conflicting dependencies. Then, the right thing to do is to figure out for given file which artefact it belongs to. To do that, it is needed to take an artefact root modules (either exposed modules for library artefact, main module for executable artefact, etc) and try traverse all dependencies from current package. Then find which artefact current module/file belongs to and load corresponding artefacts ghc options.
This is too much work and IMO could be rarely seen to invest in implementing that.
@maximkulkin I'll give it a whirl! Thanks!
@maximkulkin works great. Thank you very much. You just saved me a few hours of my life! I cherry picked your commit on top of Schell's fork. My own fork: https://github.com/jsantos17/hdevtools
Any news on this issue? I'm currently running into the problem.
@davidpdrsn - @maximkulkin's changes are merged into my fork. Please tell me if that fixes your issue.
@schell how can I do that? I'm that experienced with cabal.
Suffering from the same issue here. Any update on the upstream?
Same problem. I'm running haskell via stack. Also, the suggested -v
flag doesn't work.
$ hdevtools check list-ops_test.hs
/Users/jon/exercism/haskell/list-ops/list-ops_test.hs:3:8:
Could not find module ‘Test.HUnit’
Use -v to see a list of the files searched for.
$ hdevtools check -v list-ops_test.hs
Unknown flag: -v
The message you see is from GHC itself, so in order to use "-v" flag you need to pass it via --ghcopts "-v"
Problem still not fixed upstream. @schell : your fork works well for me. For the nix users like myself:
{ mkDerivation, base, bin-package-db, Cabal, cmdargs, directory
, filepath, ghc, ghc-paths, network, process, syb, time, unix, fetchFromGitHub
, stdenv
}:
mkDerivation {
pname = "hdevtools";
version = "0.1.2.1";
src = fetchFromGitHub {
owner = "schell";
repo = "hdevtools";
rev = "d331b7f5d98591ffceaa8306d3205b647466d25a";
sha256 = "06qg2xg40jc77gn7ms8h9xscja3v69paa6yb54iz1pc92l19r180";
};
isLibrary = false;
isExecutable = true;
executableHaskellDepends = [
base bin-package-db Cabal cmdargs directory filepath ghc ghc-paths
network process syb time unix
];
homepage = "https://github.com/bitc/hdevtools/";
description = "Persistent GHC powered background server for FAST haskell development tools";
license = stdenv.lib.licenses.mit;
}
@2chilled Yes, the original author seems like have abandoned the project and you are left with option to install it from alternative repositories like @schell
@2chilled and @maximkulkin, there's a new effort at https://github.com/hdevtools/hdevtools.
(this is a bug report / feature request against master of https://github.com/schell/hdevtools /cc @schell)
Currently,
hdevtools
does not pick up test dependencies. Here is a minimal way to reproduce this: