We have two new updates to Stackage: providing
cabal.config
files and including Haddock
documentation.
Now all new exclusive snapshots will have haddock links, which you can access via the following steps:
That link will be to an index page from which you can view documentation of all packages included in the snapshot. This means you can generally view everything in one place, on one high availability service.
The recommended way to use Stackage is to simply change your
remote-repo
field in your .cabal/config
file and run cabal update
. Henceforth your
dependencies will be resolved from Stackage, which is backed by
high availability Amazon S3 storage servers, and you will have
successful build plans, compilation and passing tests. Hurrah!
Try Haskell and the upcoming Haskell.org homepage were both developed with Stackage. This meant I could just specify the Stackage snapshot to use in the README and then the next time I want to upgrade I can just update the snapshot version to get a fresh working build plan.
The issue some people are facing is that they cannot change this
remote-repo
field, either because they’re using a
cabal sandbox, which doesn’t support this yet, or because they just
don’t want to.
The solution to this, in my experience, has been for me to
manually go and run cabal freeze
in a project I’ve
already built to get the cabal.config
file and then
give these people that file.
Now, it’s automated via a cabal.config
link on
snapshot pages:
For new developers working on an application who want to use Stackage, they can do something like this:
$ cabal sandbox init
$ curl https://www.stackage.org/<stackage version>/cabal.config > cabal.config
$ cabal install --only-dep
Which will install their dependencies from Hackage. We can’t guarantee this will always work — as Stackage snapshots sometimes will have a manual patch in the package to make it properly build with other packages, but otherwise it’s as good as using Stackage as a repo.
A cabal freeze output in cabal.config
will contain
base and similar packages which are tied to the minor GHC version
(e.g. GHC 7.8.2 vs GHC 7.8.3 have different base numbers), so if
you get a cabal.config
and you get a dependencies
error about base
, you probably need to open up the
cabal.config
and remove the line with the
base
constraint. Stackage snapshots as used as repos
do not have this constraint (it will use whichever base your GHC
major version uses).
Another difference is that cabal.config
is more
like an
“inclusive” Stackage snapshot — it includes packages not known
to build together, unlike “exclusive” snapshots which only contain
packages known to build and pass tests together. Ideally every
package you need to use (directly or indirectly) will come from an
exclusive snapshot. If not, it’s recommended that you submit
the package name to Stackage, and otherwise inclusive snapshots
or cabal.config
are the fallbacks you have at your
disposal.
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.