mirror of
https://github.com/commercialhaskell/stackage.git
synced 2026-01-12 15:28:29 +01:00
4fbf45669c
Yes, it was already in the maintainer agreement, but enough people were confused about this point that it's worth putting front and center.
108 lines
5.6 KiB
Markdown
108 lines
5.6 KiB
Markdown
stackage
|
|
========
|
|
|
|
[](https://travis-ci.org/fpco/stackage)
|
|
|
|
"Stable Hackage": creating a vetted set of 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/](https://www.stackage.org).
|
|
|
|
We strongly recommend using the Haskell tool stack for doing builds, which
|
|
includes built-in Stackage support: [stack](https://github.com/commercialhaskell/stack) [](https://travis-ci.org/commercialhaskell/stack).
|
|
|
|
|
|
Add your package
|
|
----------------
|
|
|
|
We welcome all packages, provided:
|
|
|
|
* The package author/maintainer agrees to the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md).
|
|
* The package is buildable and testable from Hackage. We recommend [the Stack Travis script](http://docs.haskellstack.org/en/stable/GUIDE.html#travis-with-caching), which ensures a package is not accidentally incomplete.
|
|
* The package is compatible with the newest versions of all dependencies.
|
|
* The package is compatible with the versions of libraries that ship with GHC ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
|
|
|
|
Full details on how to add a package can be found in the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md#adding-a-package).
|
|
|
|
__NOTE__: There is an approximate 30 minute delay between a package uploading
|
|
to Hackage and being available to the Travis build script 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:
|
|
|
|
* [stackage-server](https://github.com/fpco/stackage-server) [](https://travis-ci.org/fpco/stackage-server)
|
|
* [stackage-curator](https://github.com/fpco/stackage-curator) [](https://travis-ci.org/fpco/stackage-curator)
|
|
* [stackage-types](https://github.com/fpco/stackage-types) [](https://travis-ci.org/fpco/stackage-types)
|
|
* [lts-haskell](https://github.com/fpco/lts-haskell)
|
|
* [stackage-nightly](https://github.com/fpco/stackage-nightly)
|
|
|
|
We also support some add-on tools to cabal-install to make its usage with
|
|
Stackage both easier and more secure:
|
|
|
|
* [stackage-cli](https://github.com/fpco/stackage-cli) [](https://travis-ci.org/fpco/stackage-cli)
|
|
* [stackage-update](https://github.com/fpco/stackage-update) [](https://travis-ci.org/fpco/stackage-update)
|
|
* [stackage-upload](https://github.com/fpco/stackage-upload) [](https://travis-ci.org/fpco/stackage-upload)
|
|
* [stackage-install](https://github.com/fpco/stackage-install) [](https://travis-ci.org/fpco/stackage-install)
|
|
* [stackage-build-plan](https://github.com/fpco/stackage-build-plan) [](https://travis-ci.org/fpco/stackage-build-plan)
|
|
|
|
Curious how it all fits together? See the [Stackage data
|
|
flow](https://github.com/fpco/stackage/blob/master/DATA-FLOW.md).
|
|
|
|
|
|
Build the package set
|
|
---------------------
|
|
|
|
Generally, building the package set should be done only by the Stackage build
|
|
machine by the Stackage curation team. If you're interested in trying this
|
|
yourself, please check out [the curator
|
|
guide](https://github.com/fpco/stackage/blob/master/CURATORS.md), though be
|
|
aware that this is not a recommended practice and there likely will be problems
|
|
you will need to debug yourself.
|
|
|
|
### Docker
|
|
|
|
Note: This method has been disabled for now, but may be enabled again in the future.
|
|
|
|
If you'd like to check a build plan, or perform an entire build, without
|
|
specially configuring your system, Docker may be a good approach. To check if
|
|
some modifications to `build-constraints.yaml` are valid, try the following:
|
|
|
|
1. Create a local clone of the `stackage` repo
|
|
2. Make modifications to your local `build-constraints.yaml`
|
|
3. Inside the `stackage` working directory, run the following:
|
|
|
|
```
|
|
$ docker run -it --rm -v $(pwd):/stackage -w /stackage snoyberg/stackage /bin/bash -c 'cabal update && stackage check'
|
|
```
|
|
|
|
Similarly, if you'd like to perform an entire build, you can replace the last step with:
|
|
|
|
```
|
|
$ docker run -it --rm -v $(pwd):/stackage -w /stackage snoyberg/stackage /bin/bash -c 'cabal update && stackage nightly --skip-upload'
|
|
```
|
|
|
|
## Processing
|
|
|
|
The following describes at a high level the series of steps for processing
|
|
|
|
### Nightlies
|
|
|
|
1. Get list of core packages
|
|
2. Get build constraints from list of maintained packages
|
|
3. Load up package index
|
|
4. Calculate build plan using newest versions of packages
|
|
5. Write out a YAML file with complete build plan
|
|
6. Verify that the build plan can be compiled
|
|
7. Perform the build
|
|
|
|
### LTS
|
|
|
|
1. Load up most recent build plan
|
|
2. Convert build plan into constraints for next build
|
|
3. Continue from step (3) above
|