Build Status

This repository contains the code for curating Stackage package sets and building reusable package databases. It was originally simply called the stackage package and was part of the stackage repository, but since this is a tool very few people need to use, we split it into its own package with a name to indicate it’s limited usage (curators only).

More information on Stackage:

Code explanation

We start off with constraints. Constraints state things like “package X has a given version range,” who the maintainer is for a package, the description of the system/compiler being used, etc. BuildConstraints describes the build as a whole, whereas PackageConstraints describes the constraints on an individual package.

There are two primary ways of getting a BuildConstraints. defaultBuildConstraints inspects the first GHC in the PATH environment variable to determine GHC version, core packages, core tools, etc. It then uses the Stackage.Config module to extract information on additional packages to be installed. The secondary approach is in Stackage2.UpdateBuildPlan, which will be discussed later.

BuildConstraints does not specify a build completely. That is given by a BuildPlan, which is similarly broken down into BuildPlan and PackagePlan. In order to get a BuildPlan, we need two pieces of information: the BuildConstraints, and a package index. The package index (usually downloaded from Hackage) is a collection of all of the cabal files available.

By applying a BuildConstraints to a package index (via newBuildPlan), we get a proposed BuildPlan. There is no guarantee that this BuildPlan is valid. To validate it, we use checkBuildPlan. A BuildPlan is an instance of both ToJSON and FromJSON, and therefore can be serialized to a file for later use.

When dealing with LTS Haskell, we want to be able to take a BuildPlan, and update to a newer BuildPlan that keeps all packages at the same major version. updateBuildConstraints turns a BuildPlan into a new BuildConstraints with that restriction, and updateBuildPlan applies newBuildPlan to that result. As mentioned previously: this is not a validated result, and therefore checkBuildPlan must be used.

A BuildPlan can be acted on. This is done to check that all packages compile together, run relevant test suites, test Haddock documentation is correct, and produce as artifacts both a self-contained GHC binary package database and a set of Haddock documentation. (Not yet implemented.)

A BuildPlan may be converted into a bundle to be uploaded to Stackage Server. (Not yet implemented.)



  • Much improved logic for calculating if a package needs to be rebuilt due to rebuilding a dependency
  • Include components using a dependency is check output


  • Add all-cabal-hashes-commit
  • Add tell-me-when-its-released
  • Fix warnings for parseUrl

  • Fix for latest nightly snapshot #21


  • configure-args
  • Support for GHC 8’s documentation directory location
  • Checked cabal-version in .cabal files
  • Switch to store


  • Move stackage-types into this package
  • Move stackage-build-plan into this package
  • Start building benchmarks stackage#1372
  • Add cabal-from-head
  • Include cabal file size and hash info


Move away from outdated stackage-metadata

We already have local package index functionality, which uses the correct index. See:


  • –no-rebuild-cabal
  • Fix allow-newer by simply stripping all version bounds in .cabal files
  • Fix build failure #13


  • Let test suite pass when no package index available stackage#1165


  • build-tool-overrides
  • Avoid using the cabal-install executable stackage#1107


  • New create-plan flags: --add-package, --expect-test-failure and --expect-haddock-failure
  • Package description caching


  • Use newest version of libraries #6


  • Added pcSkipBuild


  • upload-docs command


  • Redefine core packages #395
  • Add –constraint flag for create-plan

  • GHC 7.10 support


  • Restructured commands to work on server/Docker setup


  • -j/--jobs option for build flags
  • Only pass in required .haddock files (more memory efficiency)


  • Number of jobs == number of capabilities
  • --bundle-dest
  • --skip-git-push
  • Removed some of the old upload stuff
  • Better exception output (limited to 500 characters)


  • Add diff command

  • Fix bug with existing .haddock file collection


  • Add the stats command

  • Respect –summary option

  • LTS bumps: specify a goal

  • Deal better with invariant violations around unregistered packages


  • Renamed to stackage-curator


  • Switch to V2 upload by default
  • –skip-hoogle option


  • Upload bundle V2 stuff


  • Upload LTS to Hackage with the name LTSHaskell


  • loadBuildConstraints
  • More command line options


  • Print “Still Alive” while checking, to avoid Travis timeouts
  • Include stackage upload-nightly command
  • Optional plan checking


  • Command line uses optparse-applicative with additional options
  • Library profiling support during build
  • Remove cfGlobalFlags (just use package-specific flags)


  • Added justCheck and stackage check command line.

Pre-fetch all packages from Hackage to catch Hackage downtime early.

  • Return progress URL from uploadBundle

Generate a core file in bundles.

Run postBuild earlier to avoid problems from broken doc uploads.

  • Use TLS manager (to download from Github)

  • Minor fixes
  • pbGlobalInstall

First version of Stackage which is made available as its own package. The codebase has been completely rewritten at this point, to be ready for generated both Stackage Nightly and LTS Haskell distributions.