About a month ago, we released our FREE Stack mini-course. If you've never used Stack before, you should totally check out that course! This article will give you a sneak peak at some of the content in the course.
But if you're already familiar with the basics of Stack and don't think you need the course, don't worry! In this article we'll be going through another cool tool to streamline your workflow!
Most any Haskell project you create will use Cabal under the hood. Cabal performs several important tasks for you. It downloads dependencies for you and locates the code you wrote within the file system. It also links all your code so GHC can compile it. In order for Cabal to do this, you need to create a
.cabal file describing all these things. It needs to know for instance what libraries each section of your code depends on. You'll also have to specify where the source directories are on your file system.
The organization of a
.cabal file is a little confusing at times. The syntax can be quite verbose. We can make our lives simpler though if we use the "Hpack" tool. Hpack allows you to specify your project organization in a more concise format. Once you’ve specified everything in Hpack’s format, you can generate the
.cabal file with a single command.
The first step to using hpack if of course to download it. This is simple, as you long as you have installed Stack on your system. Use the command:
stack install hpack
This will install Hpack system wide so you can use it in all your projects. The next step is to specify your code’s organization in a file called
package.yaml. Here’s a simple example:
name: HpackExampleProject version: 0.1.0.0 ghc-options: -Wall dependencies: - base library: source-dirs: src/ executables: HpackExampleProject-exe: main: Main.hs source-dirs: app/ dependencies: HpackExampleProject tests: HpackExampleProject-test: main: Spec.hs source-dirs: test/ dependencies: HpackExampleProject
This example will generate a very simple cabal file. It'll look a lot like the default template of running
stack new HpackExampleProject. There are a few basic fields, like the name, version and compiler options for our project. We can specify details about our code library, executables, and any test suites we have, just as we can in a
.cabal file. Each of these components can have their own dependencies. We can also specify global dependencies.
Once we have created this file, all we need to do is run the
hpack command from the directory containing this file. This will generate our
>> hpack generated HpackExampleProject.cabal
What problems does Hpack solve?
One big problem hpack solves is module inference. Your
.cabal file should specify all Haskell modules which are part of your library. You'll always have two groups: “exposed” modules and “other” modules. It can be quite annoying to list every one of these modules, and the list can get quite long as your library gets bigger! Worse, you'll sometimes get confusing errors when you create a new module but forget to add it to the .cabal file. With Hpack, you don't need to remember to add most new files! It looks at your file system and determines what modules are present for you. Suppose you have organized your files like so in your source directory:
src/Lib.hs src/API.hs src/Internal/Helper.hs src/Internal/Types.hs
Using the normal .
cabal approach, you would need to list these modules by hand. But without listing anything in the package.yaml file, you’ll get all your modules listed in the .cabal file:
exposed-modules: API Internal.Helper Internal.Types Lib
Now, you might not want all your modules exposed. You can make a simple modification to the package file:
library: source-dirs: src/ exposed-modules: - API - Lib
And hpack will correct the
exposed-modules: API Lib other-modules: Internal.Helper Internal.Types
From this point, Hpack will infer all new Haskell modules as “other” modules. You'll only need to list "exposed" modules in package.yaml. There's only one thing to remember! You need to run
hpack each time you add new modules, or else Cabal will not know where your code is. This is still much easier than modifying the
.cabal file each time. The
.cabal file itself will still contain a long list of module names. But most of them won’t be present in the
package.yaml file, which is your main point of interaction.
Another big benefit of using hpack is global dependencies. Notice in the example how we have a “dependencies” field above all the other sections. This means our library, executables, and test-suites will all get base as a dependency for free. Without hpack, we would need to specify base as a dependency in each individual section.
There is also plenty of other syntactic sugar available with hpack. One simple example is the github specification. You can put the following single line in your package file:
And you’ll get the following lines for free in your
homepage: https://github.com/username/reponame#readme bug-reports: https://github.com/username/reponame/issues
Once you move beyond toy projects, maintenance of your package will be non-trivial. If you use hpack, you’ll have an easier time organizing your first big project. The syntax is cleaner. The organization is more intuitive. Finally, you will save yourself the stress of performing many repetitive tasks. Constant edits to the
.cabal file will interrupt your flow and build process. So avoiding them should make you a lot more productive.
Now if you haven't used Stack or Cabal at all before, there was a lot to grasp here. But hopefully you're convinced that there are easy ways to organize your Haskell code! If you're intrigued at learning how, sign up for our FREE Stack mini-course! You'll learn all about the simple approaches to organizing a Haskell project.
If you've never used Haskell at all and are totally confused by all this, no need to fret! Download our Getting Started Checklist and you'll be well on your way to learning Haskell!