-
Notifications
You must be signed in to change notification settings - Fork 805
Stackage Server FAQ
If you already have installed some packages from Hackage or elsewhere and you want to start from a fresh package set, you can remove your ~/.ghc/<os>-<ghc-version> directory.
For example, in my directory .ghc I have:
$ ls ~/.ghc/
x86_64-linux-7.2.2 x86_64-linux-7.4.2
x86_64-linux-7.6.2 x86_64-linux-7.6.3
x86_64-linux-7.8.2
If I want to clear my GHC 7.2.2. environment, all the user-installed packages, I can remove the directory x86_64-linux-7.2.2. Be careful that you are sure that you want to clear your package set (re-installing packages takes time!) and that you clear the right one.
On Windows the .ghc directory might be in a directory like C:\Documents and Settings\HaskellCurry\.
Now you can set Stackage as your remote-repo and run cabal update.
Stackage Server natively supports cabal both with and without sandboxes. The standard instructions of downloading a cabal.config file should work with any cabal release since 1.18 (possibly earlier versions as well).
Note that, previously, we used remote-repo configuration to enable Stackage, which presented problems with cabal. The cabal.config support bypasses that issue. If you still wish to use remote-repo and wish to do so with a sandbox, you'll need cabal-install 1.18.0.6 or later, or 1.20.0.4 or later.
Note that this terminology is no longer used. However, the standard cabal.config approach gives you the basics of inclusive as described below, while remote-repo gives you exclusive. At this point, cabal.config/inclusive is recommended.
Imagine that Hackage has the following packages and versions:
- foo-1.0
- foo-1.1
- bar-1.0
- bar-1.1
And let's say that foo is in Stackage, but bar is not. Stackage will select (most likely) version 1.1 of foo, and confirm that it will compile and pass tests with all the other packages in in Stackage. Then, foo-1.1 will be included in the snapshot, both of inclusive and exclusive. foo-1.0 will not be included in either snapshot.
What about bar? Stackage can give no guarantees about any version of bar compiling and working with the rest of Stackage. So there are two choices:
- Don't include bar at all.
- Include some version- or many versions- of bar.
The first option is the safest: if a package is in the snapshot, you know it compiles. The second option introduces something quite arbitrary: which version of bar should we include? Arguably, the most sensible choice is "just include all versions of bar, and hope that cabal can figure it out."
The first option is our exclusive snapshots. The second option is our inclusive snapshots. The second option is useful when there are a number of packages not available in Stackage that you want to use, while still getting most of the benefits of Stackage.
But my real recommendation is: if you want to use a package not in the current Stackage snapshot, send a pull request, get it included, and then use the next exclusive snapshot that includes it.
We'll format this more nicely in the future, for now it's just a collection of blog post links:
Homebrew ships with a Cabal version newer than Stackage expects:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3
$ cabal --version
cabal-install version 1.20.0.4
using version 1.20.0.3 of the Cabal library
Stackage uses the Cabal version that ships with GHC, so when trying to install something you may get an error like:
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: Cabal (user goal)
rejecting: Cabal-1.18.1.4/installed-d6c... (global constraint requires
==1.18.1.3)
trying: Cabal-1.18.1.3/installed-476...
trying: yesod-bin-1.4.2 (user goal)
next goal: ghc (dependency of yesod-bin-1.4.2)
rejecting: ghc-7.8.3/installed-1d5... (conflict:
Cabal==1.18.1.3/installed-476..., ghc => Cabal==1.18.1.4/installed-d6c...)
Dependency tree exhaustively searched.
The workaround is to edit your cabal.config with
- Cabal ==1.18.1.3,
+ Cabal ==1.18.1.4,