use with hsenv
Opened this issue · 11 comments
I'm not sure if this is even an issue. But I had trouble with vim-hdevtools not finding sandboxed packages in
hsenv.
I used this in my vimrc to fix it
if isdirectory($HSENV)
let g:hdevtools_options = '-g-package-conf$HSENV/.hsenv_$HSENV_NAME/ghc_pkg_db'
endif
Otherwise it works great. Thanks
What if you do cabal install hdevtools
inside of your hsenv environment? The new hdevtools
binary that is installed into your hsenv environment should inherit the package paths from the GHC that it was compiled with, and then your manual setting of the package path above shouldn't be necessary. Please let me know if this works for you.
@bitc The problem is that the ghc wasn't compiled inside the hsenv environment, and so it doesn't know anything about the package databases. These are stored, for ghc-mod for example, in the environment variable PACKAGE_DB_FOR_GHC_MOD
. Maybe this means additional support is needed on both sides.
what about when running hdevtools with the hsenv activated?
Still, it doesn't know where the package database is.
This is related to bitc/hdevtools#12
It actually appears to be working now, although I'm not sure what I did to fix it.
I wish I remembered. Here is my invocation:
/data/Home/Contracts/FPComplete/Projects/fpco/.hsenvs/ghc-7.4.2.9/.hsenv/cabal/bin/hdevtools check -g -Wall -g -XBangPatterns -g -XCPP -g -XConstraintKinds -g -XDefaultSignatures -g -XDeriveDataTypeable -g -XDeriveFoldable -g -XDeriveFunctor -g -XDeriveGeneric -g -XDeriveTraversable -g -XEmptyDataDecls -g -XFlexibleContexts -g -XFlexibleInstances -g -XFunctionalDependencies -g -XGADTs -g -XGeneralizedNewtypeDeriving -g -XImplicitParams -g -XMonadComprehensions -g -XMultiParamTypeClasses -g -XNamedFieldPuns -g -XNoMonomorphismRestriction -g -XOverloadedStrings -g -XPackageImports -g -XParallelListComp -g -XPatternGuards -g -XRankNTypes -g -XRecordWildCards -g -XScopedTypeVariables -g -XStandaloneDeriving -g -XTemplateHaskell -g -XTupleSections -g -XTypeFamilies -g -XViewPatterns /Volumes/Data/Home/fpco/gitlib/gitlib-libgit2/Git/flyparse-Libgit2.hs
So, nothing special there that might actually fix it. Another thing that I changed recently is that my global GHC is no longer the same compiler as my hsenv's GHC (7.6.3 vs. a modified 7.4.2). Maybe having that stark separation helped?
I actually fixed it. What I was forgetting was that hdevtools is a "service" which start as a server and remains there. So I was actually calling the "wrong" hdevtools, the one outside .hsenv. To make my life easier, I created this simple function:
(defun hsenv-jack-in ()
(interactive)
(shell-command "killall hdevtools")
(hsenv-activate)
(flycheck-buffer))
So, even if I forget to call "hsenv-activate" I can amend later on and see flycheck correctly checking my code :)
The checker is nothing special:
(flycheck-define-checker haskell-hdevtools
"A Haskell syntax and type checker using hdevtools.
See URL `https://github.com/bitc/hdevtools'."
:command ("hdevtools" "check" "-g" "-Wall" source-inplace)
:error-patterns
((warning line-start (file-name) ":" line ":" column ":"
(or " " "\n ") "Warning:" (optional "\n")
(one-or-more " ")
(message (one-or-more not-newline)
(zero-or-more "\n"
(one-or-more " ")
(one-or-more not-newline)))
line-end)
(error line-start (file-name) ":" line ":" column ":"
(or (message (one-or-more not-newline))
(and "\n" (one-or-more " ")
(message (one-or-more not-newline)
(zero-or-more "\n"
(one-or-more " ")
(one-or-more not-newline)))))
line-end))
:modes haskell-mode
:next-checkers (haskell-hlint))
(push 'haskell-hdevtools flycheck-checkers)
Yep, I have a killall
command happen every time I type C-c C
(which manually rechecks the current file).