Monthly Downloads: 1
Programming language: Haskell
License: Mozilla Public License 2.0
Tags: Development     Distribution     Cabal     CustomSetup     Setup    
Latest version: v0.0.0.0

autopack alternatives and similar packages

Based on the "Cabal" category.
Alternatively, view autopack alternatives based on common mentions on social networks and blogs.

Do you think we are missing an alternative of autopack or a related project?

Add another 'Cabal' Package



logo GitHub CI Build status Windows build status

Hackage Stackage Lts Stackage Nightly [MPL-2.0 license](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 and .hsc extensions 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. You may also be interested in cabal-fmt โ€“ a non-official .cabal files formatter than can optionally expand source directories during formatting.


Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY.

*Note that all licence references and agreements mentioned in the autopack README section above are relevant to that project's source code only.