I'm currently trying to use pandoc (as a Haskell module, not as a program) to convert MediaWiki text to other formats.
Let's assume this program:
import Text.Pandoc.Readers.MediaWiki
main = do print "foo"
When using runghc to run it, I get the following error message:
pandock.hs:1:8:
Could not find module `Text.Pandoc.Readers.MediaWiki'
Use -v to see a list of the files searched for.
My first assumption was that pandoc was either not installed or incorrectly installed. Therefore I reinstalled it with --force-reinstalls
$ cabal install pandoc --reinstall
[...]
In order, the following will be installed:
pandoc-1.12.3.1 (reinstall) changes: old-time-1.1.0.1 added
[...]
[32 of 55] Compiling Text.Pandoc.Readers.MediaWiki ( src/Text/Pandoc/Readers/MediaWiki.hs, dist/build/Text/Pandoc/Readers/MediaWiki.o )
[...]
Installing library in
/home/uli/.cabal/lib/x86_64-linux-ghc-7.6.3/pandoc-1.12.3.1
Installing executable(s) in /home/uli/.cabal/bin
Registering pandoc-1.12.3.1...
Installed pandoc-1.12.3.1
The output of runghc -v pandock.hs is quite long, I assume the relevant part is:
*** Chasing dependencies:
Chasing modules from: *pandock.hs
pandock.hs:1:8:
Could not find module `Text.Pandoc.Readers.MediaWiki'
Locations searched:
Text/Pandoc/Readers/MediaWiki.hs
Text/Pandoc/Readers/MediaWiki.lhs
Failed, modules loaded: none.
However, both ~/.cabal/lib/x86_64-linux-ghc-7.6.3/pandoc-1.12.3.1/Text/Pandoc/Readers/Mediawiki/MediaWiki.hi and ~/.cabal/bin/pandoc exist. How can I make GHC properly recognize the cabal-installed package?
Any help will be appreciated!
When trying to reproduce this issue on other computers, only 2 out of 5 computers had this issue. On both of them I installed cabal packages in about the same way and order.
In retrospect I assume this issue arose because of some broken packages wreaking havoc:
$ ghc-pkg check
There are problems in package feed-0.3.9.2:
dependency "xml-1.3.13-dd52b1688e97a3c6cd0aa48dba7b153e" doesn't exist
There are problems in package hxt-9.3.1.3:
dependency "network-2.4.2.2-ea77cdf1bc747bc58308fdeb52745c4d" doesn't exist
There are problems in package hspec-1.8.1.1:
dependency "QuickCheck-2.6-409fcc32c191cd6e04afdebb15869820" doesn't exist
There are problems in package quickcheck-io-0.1.0:
dependency "QuickCheck-2.6-409fcc32c191cd6e04afdebb15869820" doesn't exist
There are problems in package regex-compat-0.95.1:
dependency "regex-base-0.93.2-2023953b859e6f91efe89733d2ef5421" doesn't exist
There are problems in package regex-posix-0.95.2:
dependency "regex-base-0.93.2-2023953b859e6f91efe89733d2ef5421" doesn't exist
There are problems in package hxt-9.3.1.2:
dependency "network-2.4.2.2-ea77cdf1bc747bc58308fdeb52745c4d" doesn't exist
The following packages are broken, either because they have a problem
listed above, or because they depend on a broken package.
feed-0.3.9.2
hxt-9.3.1.3
hspec-1.8.1.1
quickcheck-io-0.1.0
regex-compat-0.95.1
regex-posix-0.95.2
hxt-9.3.1.2
MissingH-1.2.0.2
yesod-test-1.2.1
Note that neither pandoc nor yaml (I installed it after asking the question and had the exact same issues as with pandoc) are listed there.
For users also having a similar problem, please ensure:
The package is installed and you're not inside any sandbox where the package is not installed.
In the directory where you're executing the test script, ensure that there is no Text/Pandoc folder (or equivalent, depending on the package causing the problem
Run your test script with runghc -v to check if it searches the proper directory
ghc-pkg list lists your package as installed, and no packages are broken (use ghc-pkg check to check)
I solved my problem by renaming ~/.cabal and ~/.ghc. Note that I did this lacking a proper solution, I think you should only do this as a last resort.
Related
I installed the timezone-series Haskell module using cabal install timezone-series-0.1.5.1.
I then defined a module named Main.hs that starts with:
import Data.Time.LocalTime.TimeZone.Series -- from timezone-series-0.1.5.1
when I run ghc Main.hs, GHC throws the following error:
/home/ubuntu/Main.hs:2:1: error:
Failed to load interface for ‘Data.Time.LocalTime.TimeZone.Olson’
I tried explicitly including the cabal directory in GHC's search path using:
ghc -i/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/ Main.hs
This resulted in the correct path being searched, but GHC is only looking for files ending in the suffix ".hs":
Locations searched:
...
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hsig
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhsig
Cabal installed interface files instead however:
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Olson.hi
From line 318 of GHC's source code it looks like GHC ignores "*.hi" files unless it is called in single-shot mode (with the -c flag). Is this correct? (See: https://github.com/ghc/ghc/blob/67a5a91ef5e61f3b3c84481d8a396ed48cd5d96e/compiler/GHC/Unit/Finder.hs)
How can I get GHC to import this module?
An help will be greatly appreciated!
My suggested ways of installing packages in order of my preference:
Make a cabal package and add timezone-series you want to install to the build-depends field as described in the cabal manual.
Use the experimental cabal-env tool to basically automate the process of point 3 below, but then with the global environment. This makes a new build-plan every time you install a new package, so it is like removing the package environment and building it again with all the old packages and the new package added to it. You can add specific constraints like this: cabal-env "timezone-series == 0.1.5.1".
Install a package into local package environment with cabal --package-env . --lib timezone-series. You can add as many packages as you want after the --lib option to install more than one package. If you later want to use a different set of packages simply remove the .ghc.environment.* file that is generated and rerun the installation with a new set of packages. GHC will automatically use these package environment files that are in the current or parent directories. You can specify specific constraints with the --constraint option like this: --constraint "timezone-series == 0.1.5.1".
Use cabal install --lib timezone-series to install it directly into the global environment (~/.ghc/x86_64-linux-8.0.2/environments/default), this will fail if a conflicting package was installed earlier. When you run into errors you can remove that package environment and try again.
Finally, I want to note that GHC 8.0.2 is quite old, so I would advise you to upgrade if you don't have a specific reason for using that version.
I recently upgraded to Cabal 3.2 (and GHC 8.10) and I am running into some major issues that make some of my project non-buildable anymore...
Thorough description of the problem
Here is a minimal (not) working configuration that fails every time:
I start off with a clean Cabal configuration (by deleting ~/.cabal); the reason for that will appear later in the post. I run cabal update to recreate the .cabal directory and to ensure Cabal is working.
I create a project (let's call it test1) using cabal init. This is a library project with one exposed module (conveniently named Test1) that exports some dummy function foo. I run cabal build, then cabal install --lib; everything is running smooth, so far so good.
Just to be sure, I leave the project directory and fire up GHCi. I type in :m Test1 to load the module I created earlier, and it works! I can type in foo ... and see my function executed. Also, I list the content of ~/.cabal/store/ghc-8.10.xxx and see that the test1-xxx directory is there.
I then create a new project, test2, still using cabal init. This time, I configure it to be an executable, and I add test1 as a dependency (using the build-depends field). But this time when I run cabal build, I run into some issue:
~/projects/haskell/test2> cabal build
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: test2-0.1.0.0 (user goal)
[__1] unknown package: test1 (dependency of test2)
[__1] fail (backjumping, conflict set: test1, test2)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: test2, test1
It seems to me like package test1 cannot be found, however I can access it from GHCi (and GHC for that matters) and it is present in ~/.cabal/store...
But unfortunately there is more.
I create a third project, test3. This is a library, and it depends on nothing else than base (so in particular it does not depend on test1). The lib exposes one module, Test3, with one function exported, bar. I run cabal build, no problem here. But when I want to install test3 with cabal install --lib I run into some errors:
~/projects/haskell/test3> cabal install --lib
Wrote tarball sdist to
/home/<user>/projects/haskell/test3/dist-newstyle/sdist/test3-0.1.0.0.tar.gz
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] unknown package: test1 (user goal)
[__0] fail (backjumping, conflict set: test1)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: test1
It seems that it cannot find test1, although it has been installed correctly; may be this is a remnant of the failed build of test2 though...
Just to be sure, I fire up GHCi and type in :m Test3, but GHCi tells me that it cannot find module Test3 (and even suggests this is a typo and I was meaning Test1), showing that test3 indeed did not get installed, although it got successfully built...
Okay there is one more quirk to this whole situation: I create once again a new project with cabal init, called test4, which is an executable that (again) depends on nothing else than base. I keep the default Main.hs (that just prints "Hello, Haskell!"). I run cabal build: no problem. Then I run cabal install and... No problem either? I run test4 in a random location and it fires up the executable, printing "Hello, Haskell!" in the terminal...
And there is one last thing: I go to some random location and I run cabal install xxx --lib where xxx is a library package available on Hackage (for example xml) and:
~> cabal install xml --lib
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] unknown package: test1 (user goal)
[__0] fail (backjumping, conflict set: test1)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: test1
This is the reason why I need to nuke .cabal regularly... Right now I seem to be in some kind of stale state where I cannot install any library anymore.
Technical configuration and notes
I am running Cabal 3.2.0.0 and GHC 8.10.0.20200123. I installed them from the hvr/ghc PPA, and I made sure there are no other versions of those tools anywhere on my computer.
Just as a note, I am running Ubuntu 18.04.4 LTS (with XFCE so XUbuntu to be exact). Everything else (seem to be like it) is up to date.
Last thing, regarding the *.cabal files I use for building, they are pretty much the ones generated by cabal init, except I switch executable xxx for library in the case of libraries, and I simply add a exposed-modules field for exposing modules for the libraries (so Test1 for test1 and Test3 for test3 respectively). I also use build-depends in test2 to make the project depend on test1. Apart from that, they are pretty much left untouched.
Notes and thoughts
I must confess that I am new to Cabal 3; until last week I was using Cabal 1 (because I never bothered to update it; yes I know this is bad). With Cabal 1 I did not have any problem whatsoever, and I was perfectly able to install a package from local sources and depend on it in other projects...
I feel like I am doing something wrong; maybe am I not using the correct Cabal commands? I saw somewhere something about cabal new-build and cabal new-install but it does not seem to do anything more than cabal build and cabal install, at least in my case. I also wanted to investigate sandboxes but it seems that has disappeared since version 2 of Cabal.
There is also a slight possibility this is a Cabal bug, but I don't find any relevant issue on the bug tracker that may be related to my problem...
What do you think about this? What am I doing wrong? Do you see any alternative or possible fix?
Thanks a lot!
GHC environment files
A GHC installation comes with a certain number of packages out-of-the box. base is one of them but there are others, for example text. If you install GHC alone (no cabal or stack) and open ghci, it should let you import Data.Text without problems.
What if you want GHC or ghci to be aware of other compiled packages present in your filesystem? You can point GHC to additional package databases using command-line flags, but there's also the concept of package environment files.
Environments are plain text files that contain a list of package-related GHC flags. There might be a global environment at ~/.ghc/$ARCH-$OS-$GHCVER/environments/default, and there might also exist local environments which only affect GHC and ghci commands invoked inside the same folder. The exact rules for search are described in the GHC User Guide.
What does cabal install --lib actually do?
By default, it modifies the global environment file, so that GHC and ghci can now find that library. That's why point 3) worked. The actual compiled binaries of the library still reside in the cabal store though.
We can also create local environment files. For example cabal install sop-core --lib --package-env . will create the environment file .ghc.environment.xxx in the current folder, and the library will be available to ghc and ghci when they are invoked there.
Why isn't test1 available for test2?
Modern cabal makes a distinction between local packages and external packages.
local packages is the set of packages you are developing together in a project, being edited, recompiled and changed repeatedly. They are built "inplace" and not seen outside the project. They can depend on each other.
external packages are dependencies from build-depends: whose source code is downloaded from a package repository and which, when compiled, are put in the cabal store so that other Cabal projects might make use of them without re-compiling.
The list of local packages and other project-level configuration details are specified in a cabal.project file. But you don't need one if you work on a single isolated package; the default list of packages is simply ./*.cabal.
cabal wants to completely control the build environment of local packages, and will ignore the global environment file. In your case, you'll have to make test1 and test2 local packages in the same project (likely the best option) or publish test1 and treat it as an external package.
Note that "cabal project" is a concept relevant only during development. Packages are published independently, there are no "projects" in Hackage or other repositories, just packages.
What if I want to treat test1 as external without publishing it to Hackage?
You will have to set up a local package repository, basically a non-public Hackage.
You can tell Cabal about additional package repositories in the Cabal configuration file, that is, the file that configures cabal itself. Its location is given in the last line of cabal --help.
But how to set up the repository? The hackage-repo-tool can help with that.
Why did test3 fail? Why did further library installs fail?
That's weird, I have no idea why that happens. Did you by perchance delete the ~/.cabal folder between steps 3) and 5) ? What happens if you delete the global GHC environment file and try again?
I tried running my program which uses Haskell QuickCheck via ghc MyProgramm.hs , but received the following error:
$ ghc Ex2.hs
[1 of 1] Compiling Ex2 ( Ex2.hs, Ex2.o )
Ex2.hs:21:1: error:
Could not find module ‘Test.QuickCheck’
There are files missing in the ‘QuickCheck-2.11.3’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
21 | import Test.QuickCheck (
| ^^^^^^^^^^^^^^^^^^^^^^^^...
I installed stack, ran stack update and stack install QuickCheck without issue but the error persisted. Then, I ran cabal install QuickCheck and got the following errors:
$ cabal install QuickCheck
Resolving dependencies...
Configuring QuickCheck-2.12.4...
Building QuickCheck-2.12.4...
Failed to install QuickCheck-2.12.4
Build log ( /home/username/.cabal/logs/ghc-8.4.3/QuickCheck-2.12.4-3d2YDDqfPBn4BfmTJbpJXK.log ):
cabal: Entering directory '/tmp/cabal-tmp-9133/QuickCheck-2.12.4'
Configuring QuickCheck-2.12.4...
Preprocessing library for QuickCheck-2.12.4..
Building library for QuickCheck-2.12.4..
[ 1 of 16] Compiling Test.QuickCheck.Exception ( Test/QuickCheck/Exception.hs, dist/build/Test/QuickCheck/Exception.o )
[ 2 of 16] Compiling Test.QuickCheck.Random ( Test/QuickCheck/Random.hs, dist/build/Test/QuickCheck/Random.o )
Test/QuickCheck/Random.hs:10:1: error:
Could not find module ‘System.Random’
There are files missing in the ‘random-1.1’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
10 | import System.Random
| ^^^^^^^^^^^^^^^^^^^^
Test/QuickCheck/Random.hs:11:1: error:
Could not find module ‘System.Random.TF’
There are files missing in the ‘tf-random-0.5’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
11 | import System.Random.TF
| ^^^^^^^^^^^^^^^^^^^^^^^
Test/QuickCheck/Random.hs:12:1: error:
Could not find module ‘System.Random.TF.Gen’
There are files missing in the ‘tf-random-0.5’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
12 | import System.Random.TF.Gen(splitn)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cabal: Leaving directory '/tmp/cabal-tmp-9133/QuickCheck-2.12.4'
cabal: Error: some packages failed to install:
QuickCheck-2.12.4-3d2YDDqfPBn4BfmTJbpJXK failed during the building phase. The
exception was:
ExitFailure 1
However, I already have the arch packages haskell-random, haskell-tf-random and haskell-mwc-random installed. Does anybody know how to fix this?
Edit: I also ran cabal install random --reinstall.
Problem
On Archlinux as of 2022-09-17, pacman -S ghc cabal-install will install
system packages that provide only dynamic files (.so, .dyn_hi) in
installed packages inside /usr/lib/ghc-*; static files (.a, .hi) are (for
the most part) missing. However, the default cabal configuration enables static file
building. Unfortunately, upstream cabal-install doesn't track whether or not
static files are available inside installed packages. It just assumes they
are, and when they are gone, it fails with errors such as you have found:
[1 of 1] Compiling Main ( Main.hs, ../setup.dist/work/depender/dist/build/depender/depender-tmp/Main.o )
Main.hs:3:1: error:
Could not find module `Dynamic'
There are files missing in the `dynamic-1.0' package,
try running 'ghc-pkg check'.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
| import qualified Dynamic (number)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Workaround
A quick workaround just to get up and running quickly is to disable static file
building, which is by default enabled. (Note that trying to pass package-local
flags to disable static file with e.g. --enable-shared --enable-executable-dynamic --disable-library-vanilla (which is how most if
not all current Archlinux Haskell packages seem to build packages, e.g. with
https://github.com/archlinux/svntogit-community/blob/master/haskell-scientific/trunk/PKGBUILD)
building using cabal-install may be ignored due to another, related bug; but
~/.cabal/config is a safe bet.) You may do so by adding 3 lines to
~/.cabal/config in the appropriate location:
library-vanilla: False
shared: True
executable-dynamic: True
(Alternatively, consider using alternative tools like stack.)
More complete solution
For a more long-term solution, one option involves 2 pieces: 1) one or more
system packages that provide all types of build artifacts, static and dynamic,
for the base, foundational packages (from GHC and cabal-install), at least as an option besides dynamic-only packages (secondary Haskell packages are optional,
since cabal-install can rebuild these with needed build artifacts (static or
dynamic)), and 2) patching cabal-install (and ghc-pkg, which can handle .conf
files recording information about installed packages) to track whether static
files are available, and to be aware of these when resolving dependencies so
that cabal-install knows when to prefer rebuild a source package with needed
build artifact configuration over an already installed package that doesn't
provid required build artifacts.
There is a merge request (I submitted) that provides such a patchset, called
fix-dynamic-deps, at https://github.com/haskell/cabal/pull/8461. For users
running into exactly the problem that you described (myself included), I also
created an AUR package that provides both pieces based on GHC 9.4.2 with Cabal
3.9.0.0 that includes my patchset (there is a mirror at
https://github.com/bairyn/ghc-cabal-arts.) It provides ghc and
cabal-install but includes both of these pieces.
Further reading
Here are a few more resources I wrote on or are related to this bug:
https://wiki.archlinux.org/index.php?title=Haskell&diff=745459&oldid=738269#Troubleshooting
https://github.com/haskell/cabal/pull/8461
https://github.com/bairyn/ghc-cabal-arts
https://github.com/bairyn/cabal/tree/fix-dynamic-builds
Even though I have a main = do and couldn't get it working that way, I was able to run my QuickCheck test as follows:
To run a quickCheck, first load your program with:
$ ghci MyProg.hs
Then to run the quickCheck, find the test you want to run, then run it with:
$ quickCheck my_quick_check
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.
I'm trying to install a package (nymphaea as it happens). This depends on an earlier version of base than the one I have. I'm not keen on downgrading my base libraries, so I'd like to try to just ignore that dependency, and see how things go.
Is there a way to tell cabal to miss out a particular dependency?
Update: After I edit the cabal file, what do I do with it? Cabal doesn't have an obvious way to point it at a file, nor anywhere I can manually put cabal files, as far as I can tell.
[As per below, apparently I should just invoke cabal install in a directory containing the edited cabal file ]
Update 2: Unfortunately, cabal gives me a weird error about package versions being required which I appear to have:
$ cabal install -v --upgrade-dependencies time
Reading available packages...
Resolving dependencies...
In order, the following would be installed:
time-1.2.0.5 (new version)
Extracting
C:\Users\Marcin\AppData\Roaming\cabal\packages\hackage.haskell.org\time\1.2.0.5\time-1.2.0.5.tar.gz
to C:\Users\Marcin\time-1.2.0.54736...
Creating C:\Users\Marcin\time-1.2.0.54736\time-1.2.0.5\dist\setup (and its
parents)
C:\Program Files (x86)\Haskell Platform\2011.2.0.1\bin\ghc.exe --make C:\Users\Marcin\time-1.2.0.54736\time-1.2.0.5\Setu
p.hs -o C:\Users\Marcin\time-1.2.0.54736\time-1.2.0.5\dist\setup\setup.exe -odir C:\Users\Marcin\time-1.2.0.54736\time-1
.2.0.5\dist\setup -hidir C:\Users\Marcin\time-1.2.0.54736\time-1.2.0.5\dist\setup -i -iC:\Users\Marcin\time-1.2.0.54736\
time-1.2.0.5 -package Cabal-1.10.1.0
<command line>: cannot satisfy -package Cabal-1.10.1.0:
Cabal-1.10.1.0-55f781465ee9f32289755ad706c71f0f is unusable due to missing or recursive dependencies:
directory-1.1.0.0-3a2367d72569467a8af8a231656ff1b8 process-1.0.1.5-b3dded8e54a2e13d22af410bdcfafff4
(use -v for more information)
World file is already up to date.
cabal.exe: Error: some packages failed to install:
time-1.2.0.5 failed during the configure step. The exception was:
ExitFailure 1
To follow up on the comments to Don's answer:
First, grab the package from Hackage.
$ cabal unpack nymphaea
Then edit the .cabal file and change base <= 4.1.0.0 to base > 3 && < 5.
$ cd nymphaea-0.3
$ vim nymphaea.cabal
Now, try to install it.
$ cabal install
I got it to work with this change using Haskell Platform 2011.2.0.1 on Ubuntu Natty after installing the required Debian packages.
You must edit the .cabal file associated with the package and remove any constraints on base that you see. Change, for example,
base < 3
to
base >= 3 && < 5
And see if it compiles. If it works, you might bump the version and let the maintainer know. If they don't respond, you might upload the fixed version to Hackage yourself.