haskell-mega-repo
Sometimes you need to make a change across the package boundaries
Maintaining
Tracking the master
Update external gitmodules:
git submodule foreach git checkout master
git submodule foreach git pull
Package dependencies
stack exec mega-repo-tool packdeps
Rough stats
stack exec mega-repo-tool stats
Update deps graph
stack exec mega-repo-tool dot
LTS version bumps
outdated
git submodule foreach git checkout master
vim -p $(find . -name stack-lts-3.yaml)
STACK_YAML=stack-lts-3.yaml stack test --pedantic
# Or if really want to test each package separately
export STACK_YAML=stack-lts-3.yaml
for i in favicon-app flowdock-grep; do echo $i; cd $i; stack test --pedantic; cd ..; done
# Commit each package changes...
Futurice Haskell Guidelines
Definitions
The packages can be divided into two groups: applications and libraries. The characteristics of these groups differ, so we apply different guidelines
Style guide
We adhere to Johan Tibell's styleguide.
We use stylish-haskell.
Example stylish-haskell.yaml
.
Packages have to be buildable with -Wall -Werror
with some of the supported
GHCs (currently usually 7.10.2).
GHC Extensions
See ghccaniuse. Don't use extensions,
which aren't supported by three or four GHC releases, i.e. using DataKinds
and other type-system extensions are ok (required by e.g. servant
anyway).
For applications, new and straight-forward extensions like DeriveAnyClass
,
PartialTypeSignatures
, or upcoming ApplicativeDo
, StrictData
or
SignatureSections
are ok as well. However, their usage isn't an end in
itself.
Also of TupleSections
and RecordWildCards
are ok.
In fact we (should) use following set of default-extensions
:
default-extensions:
- DeriveDataTypeable
- DeriveFoldable
- DeriveFunctor
- DeriveGeneric
- DeriveTraversable
- NoImplicitPrelude
- ScopedTypeVariables
Don't use UnicodeSyntax
.
Use CPP
sparingly. If you can get away with compat package (e.g.
base-compat
). Some
warnings with other GHCs are ok.
Three release policy
Everything should be compilable with the last three releases of GHC.
We don't apply the three release policy for the applications. It's enough that we can compile applications with some recent GHC version (currently 7.8.4).
For libraries we aim to support the last three GHC versions (currently: 7.6.3, 7.8.4 and 7.10.2), as well the last three Stackage LTS snapshots (currently only two: lts-2.22 and lts-3).
Stackage support is not strict. For example the API of
servant
changes with every
major release, so supporting multiple releases is not worth the trouble.
GHC 7.6.3 support is not strict. As we haven't used it in production, we support it, if it doesn't require additional work. When GHC 8.0 will be released, the GHC part of thre three release policy will be strict(er).