wai-devel depends on the environment variable GHC_PACKAGE_PATH and having the system ghc version be the one the application depends on.
The temporary fix for this is running wai-devel via stack exec. That is: stack exec wai-devel
A longer way and not recommended of doing this for yesod applications is setting the GHC_PACKAGE_PATH to: export GHC_PACKAGE_PATH=~/.stack/snapshots/x86_64-linux/lts-2.22/7.8.4/pkgdb: because that's the package path a fresh yesod scaffold currently looks for. Then have your system ghc version be 7.8.4 which can be done via: PATH=$PATH:/home/urbanslug/.stack/programs/x86_64-linux/ghc-7.8.4/bin
Have that come before other GHC versions being added to path.
This means wai-devel is very brittle and breaks when small environment changes occur. Stack have a way of getting around this. I will look at how they (stack developers) have implemented it and close this issue when fixed.
wai-devel depends on the environment variable
GHC_PACKAGE_PATH
and having the system ghc version be the one the application depends on.The temporary fix for this is running wai-devel via stack exec. That is:
stack exec wai-devel
A longer way and not recommended of doing this for yesod applications is setting the GHC_PACKAGE_PATH to:
export GHC_PACKAGE_PATH=~/.stack/snapshots/x86_64-linux/lts-2.22/7.8.4/pkgdb:
because that's the package path a fresh yesod scaffold currently looks for. Then have your system ghc version be 7.8.4 which can be done via:PATH=$PATH:/home/urbanslug/.stack/programs/x86_64-linux/ghc-7.8.4/bin
Have that come before other GHC versions being added to path.
This means wai-devel is very brittle and breaks when small environment changes occur. Stack have a way of getting around this. I will look at how they (stack developers) have implemented it and close this issue when fixed.