summoner: Tool for creating completely configured production Haskell projects.

This is a package candidate release! Here you can preview how this package release will appear once published to the main package index (which can be accomplished via the 'maintain' link below). Please note that once a package has been published to the main package index it cannot be undone! Please consult the package uploading documentation for more information.

[maintain] [Publish]

Tool for creating completely configured production Haskell projects. See for details.

[Skip to Readme]


Versions 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.6, 1.1.0,, 1.2.0, 1.3.0,,,,,
Change log
Dependencies aeson, ansi-terminal, base (>=4.9 && <5), bytestring, directory, filepath, generic-deriving, neat-interpolation, optparse-applicative, process, relude, summoner, text, time, tomland (>=0.3 && <0.4) [details]
License MPL-2.0
Copyright 2018 Kowainik
Author Kowainik
Category CLI, CLI Tool, Development
Home page
Bug tracker
Source repo head: git clone
Uploaded by shersh at 2018-07-23T11:46:46Z




Maintainer's Corner

For package maintainers and hackage trustees

Readme for summoner-1.0.6

[back to package description]

🔮 Summoner

Build status MPL-2.0 license Hackage Stackage LTS Stackage Nightly

This is tool for creating completely configured production Haskell projects.



Getting started


To start using it make sure you have next tools installed on your machine:


Installation process can be done with one simple command:

$ cabal install summoner


$ stack install summoner

You can turn on the bash auto-completion by running the following command:

$ source <(summon --bash-completion-script `which summon`)

After that you can call summon with required command line options, follow the instructions that will appear, and a new project would be created in a subfolder as well as a repository under your github account (if requested).


There are several options how to set particular configurations:

  1. Default configuration file (~/.summoner.toml).
  2. Explicitly specified configuration file by --file FILENAME option (used instead of default one if specified).
  3. Options that are stated by CLI arguments.
  4. Interactively inputed answers during work of the summon command (for the options that were not specified on previous steps).

So the configuration uses Partial Options Monoid Pattern.

If none of the mentioned above cases used then the configuration will be built interactively.


.toml files:

Here is the list of the options that could be configured for your needs:

Global keys
Custom prelude options

Should be specified inside [prelude] table.


See example of configuration for projects of Kowainik organization.

By default the summoner will look for the configuration file (.summoner.toml) in home directory.

The other way to specify some particular .toml file is summon PROJECTNAME --file FILEPATH command.


See the basic usage syntax below (you can check it out with summon --help command):

summon PROJECT_NAME [--cabal] [--stack] [--ignore-config]
       [with [OPTIONS]] [without [OPTIONS]]
       [-f|--file FILENAME]  [--prelude-package PACKAGE_NAME]
       [--prelude-module MODULE_NAME]

Available global options:
  -h, --help               Show this help text
  -v, --version            Show summoner's version
  --ignore-config          Ignore configuration file
  --cabal                  Cabal support for the project
  --stack                  Stack support for the project
  -f, --file FILENAME      Path to the toml file with configurations. If not
                           specified '~/.summoner.toml' will be used if present
  --prelude-package PACKAGE_NAME
                           Name for the package of the custom prelude to use in
                           the project
  --prelude-module MODULE_NAME
                           Name for the module of the custom prelude to use in
                           the project

Available commands:
  with                     Specify options to enable
  without                  Specify options to disable

Available command options:
  -h,--help                Show this help text
  -g, --github             Github integration
  -p, --private            Create private GitHub repository
  -c, --travis             Travis CI integration
  -w, --app-veyor          AppVeyor CI integration
  -s, --script             Build script
  -l, --library            Library target
  -e, --exec               Executable target
  -t, --test               Tests
  -b, --benchmark          Benchmarks

The options to be enabled/disabled can be specified while running the command. If any of applicable command options wasn't tagged as enabled/disabled then the question will be asked during the work of the script.

For example,

  summon newProject with -letgcspw without -b --prelude-package relude --prelude-module Relude

will create fully functional project which uses custom prelude relude, contains library, executable file, tests, build script and create private repository on github integrated with Travis-CI, AppVeyor-CI, but benchmarks won't be attached to this one.

But when calling this command

  summon newProject

the tool will ask about every particular option, rather you'd like to have it or not in your project.


This tool was tested with next settings:

stack version 1.6.1
git   version 2.11.0
hub   version 2.2.9


If you're running the summoner with all options enabled a project with the following hierarchy will be created:

├── app
│   └── Main.hs
├── benchmark
│   └── Main.hs
├── src
│   ├── ProjectName.hs
│   └── Prelude.hs
├── test
│   └── Spec.hs
├── project-name.cabal
├── Setup.hs
├── stack.yaml
├── appveyor.yml
├── .git
├── .gitignore
└── .travis.yml

and also repository with one commit at master will be added with enabled Travis-CI for that.

Build script

The b script builds the project in a way that is convenient for developers. It passes the right flags into right places, builds the project with --fast, tidies up and highlights error messages in GHC output.


  ./b                 build whole project with all targets
  ./b -c              do stack clean
  ./b -t              build and run tests
  ./b -b              build and run benchmarks
  ./b --nix           use nix to build package

Change log

List of changes.


This project was inspired by Aelve/new-hs, which is the tool with the same goal but it's using cabal for creating projects.