mirror of
https://github.com/commercialhaskell/stackage.git
synced 2026-01-11 23:08:30 +01:00
Clarify the addition of packages and building the package set.
* Packdeps can be used to make sure a package supports the latest version of all its dependencies. * The all-cabal-files repository can be used to check if newly released packages have been synced. * People who want to make an os distribution of stackage may also want to build the entire package set. * Delete old text about the disabled docker image.
This commit is contained in:
parent
fa27ed94b3
commit
2086eb0f14
@ -3,7 +3,7 @@ This project is built around the concept of maintainers taking responsibility fo
|
||||
The idea behind Stackage is that, if all packages work with the newest versions of dependencies, we avoid dependency hell. Specifically, we aim for:
|
||||
|
||||
* All packages are 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.
|
||||
* All packages are compatible with the newest versions of all dependencies.
|
||||
* All packages are compatible with the newest versions of all dependencies (You can verify this by checking http://packdeps.haskellers.com/feed?needle=PACKAGENAME).
|
||||
* All packages in a snapshot are compatible with the versions of libraries that ship with the GHC used in the snapshot ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
|
||||
|
||||
## Adding a package
|
||||
@ -25,10 +25,12 @@ After doing that, send a pull request (with a commit message like "add foo-bar")
|
||||
(`build-constraints.yaml` is the most frequently changed file in this git repo
|
||||
so commit messages like "update build-constraints.yaml" are not helpful).
|
||||
|
||||
**NB2** There can be a delay of up to an hour before package versions newly
|
||||
uploaded to Hackage appear to our build server. If you just uploaded a package
|
||||
to Hackage that you're trying to get included, we recommend waiting an hour
|
||||
before opening the PR.
|
||||
**NB2** There can be a delay of up to an hour before package versions
|
||||
newly uploaded to Hackage appear to our build server. If you just
|
||||
uploaded a package to Hackage that you're trying to get included, we
|
||||
recommend waiting an hour before opening the PR. You can also verify
|
||||
this by making sure the latest version is listed in
|
||||
https://github.com/commercialhaskell/all-cabal-files/tree/master/PACKAGENAME.
|
||||
|
||||
|
||||
## Uploading a new package
|
||||
|
||||
37
README.md
37
README.md
@ -18,7 +18,7 @@ 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 newest versions of all dependencies (You can verify this by checking 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](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).
|
||||
@ -57,34 +57,13 @@ 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'
|
||||
```
|
||||
Generally only the stackage build server run by the stackage curator
|
||||
team and people intrested 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](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.
|
||||
|
||||
## Processing
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user