stackage

Stable sets of Haskell Packages from Hackage

This repository is for package authors and maintainers to get their packages into Stackage.

If you simply want to use Stackage as an end user, please follow the instructions on https://www.stackage.org/.

We strongly recommend using the Haskell stack tool for doing builds, which includes built-in Stackage support.

Add your package

We welcome all packages, provided:

The package author/maintainer agrees to the maintainers agreement.
The package is buildable and testable from Hackage. We recommend the Stack Travis script, which ensures a package is not accidentally incomplete.
The package is compatible with the newest versions of all dependencies (You can find restrictive upper bounds by visiting http://packdeps.haskellers.com/feed?needle=PACKAGENAME).
The package is compatible with the versions of libraries that ship with GHC (more information on lenient lower bounds).

Full details on how to add and test a package can be found in the maintainers agreement.

NOTE: There is an approximate 30 minute delay between a package uploading to Hackage and being available to the Github workflow action to check upper bounds. If a pull request is marked as failed due to using an older version, please close and reopen the PR to retrigger a Travis build.

Other repos

The Stackage project consists of multiple repositories. This repository contains the metadata on packages to be included in future builds and some project information. In addition, we have the following repositories:

Curious how it all fits together? See the Stackage data flow.

Build the package set

Generally only the stackage build server run by the stackage curator team and people interested in incorporating stackage snapshots into an OS distribution need to build the entire package set. If you're interested in trying this yourself, please check out the curator guide, though be aware that this is not a recommended practice and there likely will be problems you will need to debug yourself.

Processing

The following describes at a high level the series of steps for processing

Nightlies

Get list of core packages
Get build constraints from list of maintained packages
Load up package index
Calculate build plan using newest versions of packages
Write out a YAML file with complete build plan
Verify that the build plan can be compiled
Perform the build

LTS

Load up most recent build plan
Convert build plan into constraints for next build
Continue from step (3) above

Frequently Asked Questions

Why is Stackage LTS still on an older version of GHC?

Typically it takes some months from a new major ghc release before the Haskell ecosystem supports it fully enough that we can push it to a new stable Stackage major version release. There can also be ghc regressions that hold up a LTS major release.

The lag for minor ghc releases should be less but it still requires extra work and there is usually some delay - this also allows for some community testing before updating LTS.

Why does Stackage have an older version of a package than Hackage?

There are a number of answers to this question:

Simplest reason: how old of a Stackage snapshot are you using? Once a snapshot is created, it's frozen for all time. So if you use nightly-2016-01-01, by the time you get to 2018, it will be pretty dated.
If you're using an LTS snapshot: we lock down major versions when first creating an LTS run, so subsequent minor versions will not get new versions necessary. For example, if LTS 6.0 has foo version 1.2.3, and the author immediately thereafter releases a version 1.3.0 and never releases another 1.2.* version, you'll never get another update in the LTS 6 line
Sometimes we have upper bounds in place because other packages have problems with newer versions of dependencies. Open up the build-constraints file and search for "Stackage upper bounds"
Wired-in packages - those that ship with GHC and cannot be upgraded, and packages depending on them - are fixed to GHC versions. Common examples of this are containers and transformers. There's a lot more information on this in an FP Complete blog post

How long do you maintain an LTS build?

We only guarantee that we will maintain a single LTS major version at a time, and that it will be maintained for at least three months. This is the originally proposed support window, and hasn't changed since then.

That said, we do maintain the capability to keep multiple LTS runs operational in parallel, and with LTS 6 and 7 in fact did so. We aren't changing our guarantees yet on longevity of a release, but are trying to push out the bounds a bit farther.

What time are Stackage snapshots published?

Stackage Nightly and LTS are not released at a fixed time of day, they get pushed to stackage.org (and the metadata to the stackage-snapshots github repo) when their builds finish on the Stackage build server and the latest built haddocks have been synced over. This time varies greatly depending on build times for package updates, bounds breakage, problems with new packages being added and other build issues, etc. There are days when a release does not happen. LTS releases tend to happen over the weekend or early in the week.

Where to get help regarding uploading packages?

Please ask on the #stackage channel on the Haskell Foundation Slack or open an issue or comment on the PR which uploads the package.

License

bravit/stackage

ErrorLooks like something went wrong!

About

Resources

License

Code of conduct

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Languages

Error
Looks like something went wrong!

Packages