stackage-curator alternatives and similar packages
Based on the "stackage" category.
Alternatively, view stackage-curator alternatives based on common mentions on social networks and blogs.
10.0 9.8 stackage-curator VS stackage"Stable Hackage": vetted consistent packages from Hackage
An executable for downloading a Haskell setup
A more secure version of cabal upload which uses HTTPS
A CLI executable for cabal-based stackage commands
Update your package index incrementally (requires git)
Tool for extracting metadata on all packages
Secure download of packages for cabal-install
Calculate and print (in different formats) Stackage build plans
Do you think we are missing an alternative of stackage-curator or a related project?
NOTE This repo is no longer used by the curator team. Instead, we've moved over to a new tool that leverages pantry at: https://github.com/commercialhaskell/curator/
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:
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
There are two primary ways of getting a
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
BuildConstraints does not specify a build completely. That is given by a
BuildPlan, which is similarly broken down into
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
get a proposed
BuildPlan. There is no guarantee that this
valid. To validate it, we use
BuildPlan is an instance of
FromJSON, and therefore can be serialized to a file for
When dealing with LTS Haskell, we want to be able to take a
update to a newer
BuildPlan that keeps all packages at the same major
updateBuildConstraints turns a
BuildPlan into a new
BuildConstraints with that restriction, and
newBuildPlan to that result. As mentioned previously: this is not a
validated result, and therefore
checkBuildPlan must be used.
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.)
BuildPlan may be converted into a bundle to be uploaded to Stackage Server.
(Not yet implemented.)