Skip to content

Stackage Server FAQ

Jump to bottom Edit New page
Michael Snoyman edited this page Dec 7, 2015 · 15 revisions

DEPRECATED

Note that it is now highly recommended that you use the Haskell tool Stack instead of other forms of using Stackage. The content below is kept for historical purposes only.

How do I clear my existing environment?

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.

How do I use it with sandboxes?

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.

What's the difference between inclusive and exclusive snapshots?

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.

Why should I use Stackage Server?

We'll format this more nicely in the future, for now it's just a collection of blog post links:

Homebrew users

NOTE: The comments below are no longer relevant, as constraints on core packages are now given by installed constraints. Below content is kept for posterity:

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,

I'd like to link to the most recent LTS/Nightly, what URL can I use?

Let's take a quick step back and describe how snapshots work in general. Every snapshot on stackage.org is uniquely identified in two different ways:

  • Its PackageSetIdent, which is a SHA1 hash of its bundle file, and is almost never seen by end users
  • Its SnapSlug, which is just a standard slug

Every snapshot uploaded- even those uploaded by users and not an LTS or Nightly release, have both of these identifiers. The SnapSlug makes up the canonical URL for a snapshot, like so:

In addition, for convenience, we have additional non-canonical URLs for the LTS and Nightly snapshots. For example:

These URLs work not only by themselves, but also take arbitrary suffixes, just like the canonical URLs. For example, if you visit http://www.stackage.org/snapshot/lts-1.0, you'll get a link to http://www.stackage.org/snapshot/lts-1.0/cabal.config?global=true. This URL can also be reached via:

And similarly, you can get the global cabal.config for the newest LTS 1.X release by using the URL:

or get the newest for all releases via:

As such, some useful URLs you may want to bookmark would be:

Add a custom footer
Add a custom sidebar
Clone this wiki locally