autopack: Custom Setup to automate package modules discovery

[ cabal, customsetup, development, distribution, library, mpl, setup ] [ Propose Tags ]

Custom Setup to automate package modules discovery. See README for more details.

[Skip to Readme]


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


Versions [RSS]
Change log
Dependencies base (>= && <4.14), Cabal (>=2.2 && <3.2), dir-traverse (>=0.2 && <0.3), filepath (>=1.4 && <1.5) [details]
License MPL-2.0
Copyright 2020 Kowainik
Author Veronika Romashkina, Dmitrii Kovanikov
Maintainer Kowainik <>
Category CustomSetup, Setup, Cabal, Distribution, Development
Home page
Bug tracker
Source repo head: git clone
Uploaded by vrom911 at 2020-03-19T19:10:26Z
Downloads 411 total (1 in the last 30 days)
Rating 2.25 (votes: 2) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for autopack-

[back to package description]


logo GitHub CI Build status Windows build status

Hackage Stackage Lts Stackage Nightly MPL-2.0 license

Custom Setup to automate package modules discovery.

⚠️ WARNING: autopack is in early beta phase. ⚠️


Usually, when working on a Haskell project, you end up having lots of modules. During the development, you can add, remove or rename any of them. And this is fine unless you continuously need remembering to add, remove or rename the corresponding module line in the .cabal file. Sometimes all you want is to make Cabal dealing with it, so you won't need to patch any files when performing any operations on modules. Good news, everyone! This project was created precisely to help to solve this particular issue.

How does autopack work

autopack is a Haskell library that provides custom setup functions that discover all exposed .hs files for your library from the hs-source-dirs folders. It uses this information to prehook the list of identified modules into the exposed-modules field of the library stanza of your package description.

You can use Cabal's custom setup scripts to use this library in your project. In the next section, we are going to give detailed instructions on that.

For now, all you need to keep in mind to use autopack:

  • It uses hs-source-dirs field to establish where to look up for modules.
  • It can work only with .hs extension at the moment.
  • It adds all discovered modules into exposed-modules of the library stanza.
  • If there are already some modules in the exposed-modules, autopack will concatenate lists.

How to use autopack

First, make sure that you are using the Cabal version at least 2.0 in your .cabal file. For example:

cabal-version:       2.4

Now you need to change the build-type field in your package_name.cabal file to Custom instead of the default Simple:

build-type:    Custom

Then you have to add custom-setup section before you defining your library stanza. It should have the autopack dependency so you can use it in your Setup:

    setup-depends: base
                 , autopack

And the final preparation. You should add the Setup.hs module (or replace the default one) in the root directory of the package with the following content:

import Autopack (defaultMainAutoModules)

main :: IO ()
main = defaultMainAutoModules

You are all set up now!

You can remove exposed-module field from your .cabal file completely, and autopack will discover all the .hs modules in your folders for you during the build.


As Cabal does not currently provide the feature of automatic modules discovery, there are some workarounds for this process. One of them is this library — autopack that uses Cabal's Setup feature to discover all modules during the pre-build stage of Cabal. Another tool that provides it out-of-the-box is hpack. It is the wrapper on Cabal syntax via YAML where there is no need to write modules explicitly. They are added to the exposed-modules field of the .cabal file during the YAML to .cabal step of the tool work process.


Icons made by Freepik from is licensed by CC 3.0 BY.