Stack can't find Chart or Chart-cairo, though the cabal file calls for them - haskell

I'm trying to use Haskell stack (lts-6.12 resolver) to set up and run a small demo program for Chart. I created the project with stack new, stack init, etc. then modified the generated Main.hs, adding the demo code. I also added the Chart and Chart-cairo packages to the .cabal file and ran stack build. Lots and lots of packages installed, including Chart and Chart-cairo, judging from the output, and when it was finally done, it tried to compile Main.hs, but failed with the following errors:
/home/asdf/my-project/app/Main.hs:4:8:
Could not find module ‘Graphics.Rendering.Chart.Easy’
It is a member of the hidden package ‘Chart-1.6#Chart_Cz416CvPROo70VikOoIoki’.
Perhaps you need to add ‘Chart’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
/home/asdf/my-project/app/Main.hs:5:8:
Could not find module ‘Graphics.Rendering.Chart.Backend.Cairo’
It is a member of the hidden package ‘Chart-cairo-1.6#Chart_I1HGJHEm7pvIiSoYgOrXbq’.
Perhaps you need to add ‘Chart-cairo’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
How can stack be loading these packages successfully, then be somehow unable to find them later? How can it have the nerve (jk) to ask me to put the dependencies in my .cabal file, when it has already obtained them from there to load them in the first place?
Here is the dependency list:
$ stack list-dependencies
Chart 1.6
Chart-cairo 1.6
StateVar 1.1.0.4
adjunctions 4.3
array 0.5.1.0
base 4.8.2.0
base-orphans 0.5.4
bifunctors 5.2
binary 0.7.5.0
bytestring 0.10.6.0
cairo 0.13.1.1
colour 2.3.3
comonad 4.2.7.2
containers 0.5.6.2
contravariant 1.4
data-default-class 0.0.1
deepseq 1.4.1.1
distributive 0.5.0.2
exceptions 0.8.3
filepath 1.4.0.0
free 4.12.4
ghc-prim 0.4.0.0
hashable 1.2.4.0
hmatrix 0.17.0.2
integer-gmp 1.0.0.0
kan-extensions 4.2.3
lens 4.13
machine-learning 0.1.0.0
mtl 2.2.1
old-locale 1.0.0.7
operational 0.2.3.3
parallel 3.2.1.0
prelude-extras 0.4.0.3
primitive 0.6.1.0
profunctors 5.2
random 1.1
reflection 2.1.2
semigroupoids 5.0.1
semigroups 0.18.1
split 0.2.3.1
stm 2.4.4.1
storable-complex 0.2.2
tagged 0.8.4
template-haskell 2.10.0.0
text 1.2.2.1
time 1.5.0.1
transformers 0.4.2.0
transformers-compat 0.4.0.4
unordered-containers 0.2.7.1
utf8-string 1.0.1.1
vector 0.11.0.0
void 0.7.1

If you have both an executable and library stanza, try listing
the dependencies in both.
If your executable depends on those dependencies but you've only listed
them in your library stanza you'll get that error - dependencies from
different stanzas are independent of each other.

Related

Haskell Cabal: omitting version a big mistake

I ran cabal build on a *.cabal file that doesn't have a version: specified and it seems to have confused cabal. When I put back the version specification, I got
$ cabal build
Resolving dependencies...
TODO: add support for multiple packages in a directory. Got
yah-0.1.0.0
yah-0.1.0.0
CallStack (from HasCallStack):
error, called at src\\Distribution\\Client\\ProjectOrchestration.hs:586:9 in cabal-install-3.8.1.0-inplace:Distribution.
Client.ProjectOrchestration
That is, normally the yah.cabal file would read
cabal-version: 3.0
name: yah
version: 0.1.0.0
license: etc., etc.
and cabal build was fed the above without the version and maybe without the cabal-version -- not sure. In any case, starting over with cabal init doesn't fix it, but other projects can be compiled fine.
My guess is that the various modules that are in the yah project are registered somewhere/somehow and it's not clear how to expunge that and start over. I'm on Windows, cabal 3.8.1.0. I've looked in C:\cabal, C:\ghccup, C:\Users\...\AppData\Roaming\cabal...
It looks like you have more than one .cabal file in that directory. Remove the one that's not named yah.cabal.

Stack insists on building Cabal package

I am working on a Haskell project using Stack.
Recently, we started using the lens package which requires the Cabal package as a dependency, but we switched to lens-simple because building the Cabal package was too resource intensive for some older machines that we tested building the project on.
However, despite the fact that neither lens-simple nor any of our other packages have a dependency on the Cabal package, Stack continues to try and build it.
Is there anyway to get Stack to stop this? It makes the build process very long on most machines and impossible on weaker machines.
A list of the project's dependencies:
HUnit 1.6.0.0
QuickCheck 2.12.6.1
ansi-terminal 0.8.2
array 0.5.3.0
base 4.12.0.0
binary 0.8.6.0
bytestring 0.10.8.2
call-stack 0.1.0
clock 0.7.2
colour 2.3.4
containers 0.6.0.1
deepseq 1.4.4.0
directory 1.3.3.0
erf 2.0.0.0
filepath 1.4.2.1
ghc-boot-th 8.6.3
ghc-prim 0.5.3
hspec 2.6.1
hspec-core 2.6.1
hspec-discover 2.6.1
hspec-expectations 0.8.2
integer-gmp 1.0.2.0
lens-family 1.2.3
lens-family-core 1.2.3
lens-family-th 0.5.0.2
lens-simple 0.1.0.9
mtl 2.2.2
ncurses 0.2.16
netflak 0.1.0.0
pretty 1.1.3.6
primitive 0.6.4.0
quickcheck-io 0.2.0
random 1.1
rts 1.0
setenv 0.1.1.3
stm 2.5.0.0
template-haskell 2.14.0.0
text 1.2.3.1
tf-random 0.5
time 1.8.0.2
transformers 0.5.5.0
unbounded-delays 0.1.1.0
unix 2.7.2.2
My guess is that one of your dependencies using a custom setup stanza, where Stack needs to build the Setup.hs file against the Cabal library, thus the implicit dependency. We have a bit of a discussion going already for Stackage as to whether we should provide up to date versions of the Cabal library as we do today—and risk forcing people to build a heavy dependency—versus sticking to the version of Cabal that ships with GHC.
Anyway, you can work around this with a slightly convoluted approach where you create a custom snapshot that drops the Cabal library. It would look something like this:
# stack.yaml: point to the custom snapshot
resolver: snapshot.yaml
# snapshot.yaml: use the original snapshot and add a drop-packages
resolver: nightly-2019-03-17
name: drop-cabal
drop-packages:
- Cabal

Stack won't resolve a 'hidden' dependency

I am working on my first major Haskell application, and want to add mockery to create disposable test WAI threads. Importing mockery and running stack test resulted in the compiler error:
Failed to load interface for ‘Test.Mockery.Directory’
It is a member of the hidden package ‘mockery-0.3.5’.
Perhaps you need to add ‘mockery’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
So, I added mockery to my cabal file under test dependencies. However, when I run stack build or stack test mockery is automatically removed from the cabal file.
I have also tried listing mockery-0.3.5 under extra-deps in the stack.yaml file. This unsurprisingly didn't work, since mockery is part of my lts, and extra deps is for packages outside of lts.
How can I get stack to recognize that mockery should be included as a dependency to to project?
Here is my stack.yaml:
flags: {}
ghc-options:
! '*': -Wall
packages:
- .
extra-deps: [
]
resolver: lts-9.5
I'm using stack version 1.5.1
I imagine this is a stupid build issue and look forward to confronting my obvious oversight.
In stack.yaml you declare the Stackage LTS version, a curated list of hackage dependencies that you want to depend on. You can also depend on local packages and packages in git that are not in Hackage. You may also change the versions of the packages in LTS as long as they respect the constraints of the other dependencies.
package.yaml is the build file. Any packages you want to import directly in your Haskell code must be declared in here as dependencies, even if they are explicitly declared in the stack.yaml.
Finally, when you see It is a member of the hidden package, that means that one of your dependencies is using that package, but it is not declared as a dependency in your build file.

GHC can not find installed module

My haskell installation can not find bytestring module installed by operating system
$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.ByteString.Lazy
<no location info>:
Could not find module `Data.ByteString.Lazy'
It is not a module in the current program, or in any known package.
But I have installed this module using yum:
$ rpm -ql ghc-bytestring
/usr/lib64/ghc-7.6.3/bytestring-0.10.0.2
/usr/lib64/ghc-7.6.3/bytestring-0.10.0.2/libHSbytestring-0.10.0.2-ghc7.6.3.so
/usr/share/doc/ghc-bytestring
/usr/share/doc/ghc-bytestring/LICENSE
What is wrong?
If this is happening, you should be able to figure out more via ghc-pkg list. This could happen, for example, if the binary package provided by your software repository was broken; ghc-pkg list would report that. In general, either GHC is not looking for packages in /usr/lib64/ghc-7.6.3/ or else that directory has a package.cache which was not updated to reflect the new package.
One thing that could cause GHC to look in the wrong place is if there are multiple GHCs on the machine: for example if which ghc reveals /usr/local/bin/ghc then you probably compiled GHC from source at some point and its packages are occupying some /usr/local/lib/ghc-7.6.3/package.conf.d/ folder, while your repository has installed /usr/bin/ghc which is looking in the folder you want.
Anyway, fixes: if the package.cache file exists and has a valid entry for the file, then you can run ghc -package-conf /path/to/package.cache ... to add those packages to your executable. If you have further problems, ghc -v ... is a great resource for debugging "which version of that package is being used here?" types of problems.
If the package.cache file does not exist then you've got a bigger problem, and probably the easiest way to move forward is to look for a directory under /home which appears on ghc-pkg list. Install the required package to that directory and GHC should pick up on it even though it doesn't understand these bigger contexts. You could also start working with a cabal sandbox of local packages to your project.
Situation here is similiar to C++ you have libraries used during dynamic linking stage and header used for compilation. In Fedora packages like ghc-bytestring are only libraries without headers. To install headers I had to install ghc-bytestring-devel package.
An example on Fedora 24:
server.hs:7:8:
Could not find module ‘Data.Text’
Perhaps you meant Data.Set (from containers-0.5.5.1)
Locations searched:
Data/Text.hs
Data/Text.lhs
So change to user root, then:
What packages are there?
# dnf search ghc|grep text
ghc-text.x86_64 : An efficient packed Unicode text type
ghc-boxes.x86_64 : 2D text pretty-printing library
ghc-pango.x86_64 : Binding to the Pango text rendering engine
ghc-css-text.x86_64 : CSS parser and renderer
ghc-hgettext.x86_64 : Haskell binding to libintl
ghc-attoparsec.x86_64 : Fast combinator parsing for bytestrings and text
ghc-text-devel.x86_64 : Haskell text library development files
ghc-blaze-textual.x86_64 : Fast rendering of common datatypes
ghc-css-text-devel.x86_64 : Haskell css-text library development files
ghc-hgettext-devel.x86_64 : Haskell hgettext library development files
ghc-blaze-textual-devel.x86_64 : Haskell blaze-textual library development files
So what's installed?
# rpm --query ghc-text
ghc-text-1.1.1.3-3.fc24.x86_64
# rpm --query ghc-text-devel
package ghc-text-devel is not installed
So let's install the devel package.
# dnf install ghc-text-devel
Installed:
ghc-text-devel.x86_64 1.1.1.3-3.fc24
...and compilation succeeds after that.

Error while installing Haskell DJinn - base-3.0.3.1 was excluded because of the top level dependency base -any

I tried installing Djinn by using cabal but got the following error -
$ cabal install djinn --verbose
Reading available packages...
Resolving dependencies...
cabal: cannot configure djinn-2009.9.3. It requires base ==3.*
For the dependency on base ==3.* there are these packages: base-3.0.3.1 and
base-3.0.3.2. However none of them are available.
base-3.0.3.1 was excluded because of the top level dependency base -any
base-3.0.3.2 was excluded because of the top level dependency base -any
The error message is mysterious, shouldn't base -any allow base version 3.0.3.1?
From the Haskell Mailing list:
It's not a great error message. Now, base is a special package. It comes with ghc, and cannot be upgraded. That's why Cabal will rule out all base versions but the one you already have installed. If you have a recent ghc, that'll be base-4.
Hope that helps.
AFAIK, GHC 7 does not ships base in version 3 anymore. The best idea would robably be to notify the maintainer (lennart*at*augustsson.net) to update the package. An ad-hoc fix would be to download the package from here, unpack it and manually edit the file djinn.cabal so that the dependency on base is base 4.*. It may or may not work, but most times it's worth a try.

Resources