hledger/doc/developer-guide.md

• toc

Developer guide

Quick links

|-------------------------|----------------------------------------------------------------------------| | IRC | Join #hledger (chat log; see also #ledger) | | Mail list | list.hledger.org (Gmane) | | Twitter | #ledgercli, @LedgerTips | | hledger-web demo   | demo.hledger.org | | Trello | old planning board | | Github | code.hledger.org
commits, COMMITS (turn up your volume), unreleased commits, release branch commits
build status (hydra)
open bugs, all bugs, open issues, all issues, issues with bounties, issue bounties @ bountysource.com | | Hackage | packages: hledger-lib, hledger, hledger-web, hledger-diff, hledger-interest, hledger-irr, hledger-vty, hledger-chart, *hledger*
build history/GHC compatibility: hledger-lib, hledger, hledger-web
outdated dependencies: hledger-lib, hledger, hledger-web
reverse dependencies: hledger-lib, hledger
download stats (BestHaskell) | | Stackage | hledger entry, issues
build status (jenkins), last build output: 7.4, 7.6, 7.8, 7.10 | | Debian | source packages
haskell-hledger-lib, bugs, haskell-hledger, bugs, haskell-hledger-web, bugs
binary packages
testing: hledger, bugs, hledger-web, bugs
unstable: hledger, bugs, hledger-web, bugs
all: *hledger*
popularity stats: hledger, hledger-web
PTS help | | Ubuntu | source packages
haskell-hledger-lib, bugs, haskell-hledger, bugs, haskell-hledger-web, bugs
binary packages
*hledger* | | Gentoo | hledger, hledger-web, *hledger* | | Fedora | hledger, *hledger*, Haskell SIG |

Project overview

A rough overview/blueprint for the hledger project.

Mission, principles, goals

The hledger project aims to produce:

• a practical, accessible, dependable tool for end users
• a useful library and toolbox for finance-minded haskell programmers
• a successful, time-and-money-solvent project within a thriving ecosystem of financial software projects.

Roles and activities

• newcomer/potential user
• user
• library user
• field tester
• bug wrangler
• support
• documentor
• qa
• developer
• packager
• communicator
• project manager

Documentation

Project documentation lives in a number of places:

• doc/*.md and doc/site/*.md form the hledger.org website, which is generated with hakyll[-std] and pandoc
• haddock documentation in the code appears on Hackage
• short blurbs: cabal files, module headers, HCAR, GSOC project, ..
• doc/notes.org has some old developer notes
• developer reports (profiles, benchmarks, coverage..) in doc/profs, sometimes published at hledger.org/profs

Code

The hledger repo is hosted on Github, at http://github.com/simonmichael/hledger. You can also jump there via code.hledger.org[/commits].

Quality control

Relevant tools include:

• unit tests (HUnit, make unittest)
• functional tests (shelltestrunner, make functest)
• performance tests (simplebench, make bench)
• documentation tests (make haddocktest + manual)
• ui tests (manual)
• installation tests (manual)
• code reviews

Code reviews

We held a code review party, hopefully the first of many, in July 2014 on the mail list and IRC channel. Here's the original proposal giving some motivation, and the discussion logs, note these are a good source of hledger development tips:

• 2014/7/21-25 hledger-web code & UI mail thread, IRC log

How to..

New contributors of all levels are most welcome. Here are some tips/checklists/procedures to help you get productive on the hledger project.

Suggest enhancements

Suggestions and feature requests (aka wishes) are easy to make, and can be valuable, but we don't want them to pile up ad infinitum and obscure bugs and other developer priorities. Before opening a github issue, consider:

1. Perhaps discussion is most appropriate at this stage ? #hledger or the mail list are excellent places for this. Both are archived, so the idea won't be lost.
2. We have a collection of enhancement ideas on the trello planning board. Perhaps your idea is already there, or you can add it ?
3. We have bug reports and more wishes in the bug tracker. Is your idea already there ?

When a wish does land in the bug tracker, it gets the WISH label, and the default view given by bugs.hledger.org excludes these.

Report problems

• check for related issues in the bug tracker or in the mail list archive
• discuss/confirm the issue on irc or list
• report new issues in the bug tracker

Help with testing

• review and test our documentation and web presence
• download and test the binaries on your platform
• test installing via cabal
• use the tools and test functionality, usability, browser compatibility, ui layout etc.
• check that hledger test reports no failures
• run the developer tests
• discuss/report problems via irc/mail list/bug tracker

Help with bug tracking

• get to know the bug tracker and its contents
• research and update issues
• some convenient url shortcuts:
  bugs.hledger.org
bugs.hledger.org/new
bugs.hledger.org/N

Set up for development

1. Get GHC and cabal-install installed. I recommend the stackage.org install guide. You can see which GHC versions are officially supported in the tested-with field in hledger.cabal and hledger-web.cabal. Older versions may also work.

2. Get git installed.

3. Get GNU Make installed (unless you don't care about the Makefile's conveniences). On some platforms the command will be eg gmake instead of make.

4. Get the hledger repo:

    git clone https://github.com/simonmichael/hledger.git
   

5. You might want to install or upgrade some of these haskell developer tools. If you're not sure, skip this step and return to it as needed. Be sure the cabal bin directory where these are installed (eg ~/.cabal/bin) is in your PATH.

    cabal update
    cabal install alex happy       # if you get alex/happy-related errors when building hledger
    cabal install haddock          # needed to build hledger API docs
    cabal install shelltestrunner  # needed to run hledger functional tests (may need latest git version)
    cabal install hoogle hlint     # maybe useful for searching API docs and checking code
   

   You'll also want a comfortable code editor, preferably with Haskell support. (I use emacs + haskell-mode, or occasionally IntelliJ IDEA + one of the plugins).

6. Install haskell libs required by hledger:

    cabal update
    cd hledger
    cabal sandbox init   # optional
    make installdeps     # or cabal install --only-dep ./hledger-lib ./hledger [./hledger-web]
   

   This will install the required dependencies from Hackage. If you're new to cabal, you can expect problems at this stage. The usual remedy is to ensure you start with a clean package db, eg by doing cabal sandbox init. You can simplify and speed up this step a lot by commenting out hledger-web in the PACKAGES list in the Makefile.

7. Build with cabal:

    make cabalbuild
   

   (Tip: make cabalCMD runs cabal CMD in each of the hledger packages).

8. Build with GHC:

    make bin/hledgerdev
   

   This builds hledger (and hledger-lib) with GHC directly, without using cabal, and as quickly as possible, without optimizations (the "dev" suffix is a reminder of this). I use and recommend this method for development, as it crosses package boundaries and ensures you are building the latest code. However it needs some files generated by cabal build, which is why we did that first.

Get your changes accepted

Follow the usual github workflow:

• fork the main hledger repo on github,
• git clone it to your local machine,
• git commit, after (?) pulling and merging the latest upstream changes
• git push back to github,
• open a pull request on github,
• follow up on any discussion there.

If you're new to this process, help.github.com may be useful.

Improve the documentation

• get familiar with the website and documentation online, review and test
• get familiar with the site/doc source files (see Makefile)
• set up for hledger development
• send patches with names prefixed with "doc: " (or "site: ")

Run the tests

• set up for hledger development
• cabal install shelltestrunner
• make test

Add a test

• identify what to test
• choose the test type: unit ? functional ? benchmark ?
• currently expected to pass or fail ?
• figure out where it goes
• write test, verify expected result
• get it committed

Fix a bug or add a feature

• research, discuss, validate the issue/feature on irc/list/bug tracker
• look for related tests, run the tests and check they are passing
• add a test ?
• develop a patch
• include any related issue numbers in the patch name, eg: "fix for blah blah (#NNN)"
• get it committed

Become a contributor

• after getting one or more patches committed, read and sign the contributor list & agreement
• or, ask to be added

Do code review

• review and discuss new pull requests and commits on github
• set up for development and test the latest changes in your own repo
• read the existing code docs and source
• send feedback or discuss via irc or list

Help with packaging

• package hledger for linux distros, macports, etc.
• develop mac/windows installers
• find and assist distro packagers/installer developers

Help with project management

• clarify/update goals and principles
• monitor, report on project progress and performance
• research, compare and report on successful projects, related projects
• identify collaboration opportunities
• marketing, communication, outreach
• release management, roadmap planning

Do a major release

1. cleanup
   • review working copies (laptop, server, website) & branches, commit pending changes
2. document
   • /.cabal (descriptions, tested-with, files..)
   • haddocks
   • */CHANGES
   • doc/contributors.md
   • doc/site/release-notes.md
   • doc/manual.md (commands, options, --help, ledger compatibility..)
   • doc/site/step-by-step.md
   • doc/site/how-to-*
   • doc/site/faq.md (ledger compatibility)
   • doc/site/installing.md
   • doc/ANNOUNCE
3. test
   • coarse tests
     • make unittest
     • make functest
     • make haddocktest
4. branch
   • start release branch (git checkout -b X.Y)
5. version
   • edit .version
   • make setversion
   • double-check, commit (cabal files, manual, download page..)
6. package
   • check Makefile's PACKAGES includes all
   • make cabalsdist
   • [make windows binaries]
   • [make osx binaries]
7. test
   • fine tests
     • install from tarballs into a clean directory
8. tag
   • make tagrelease
9. push
   • git push --tags
10. upload
    • make hackageupload
11. announce
    • email hledger haskell-cafe haskell [ledger]
    • tweet
    • [blog]
    • [reddit]
    • add announcement link, update short description in release notes
12. deploy at demo.hledger.org
13. issues
    • review/close open issues in tracker

Do a minor release

Differences from a major release: set PACKAGES only to the affected package(s), don't run make setversion. Use make -n if unsure.

1. cleanup
   • review working copies (laptop, server, website) & branches, commit pending changes
2. document
   • /.cabal for affected package(s) (descriptions, tested-with, files..)
   • */CHANGES for affected package(s)
   • doc/site/release-notes.md
   • doc/manual.md (commands, options, --help, ledger compatibility..)
   • doc/site/step-by-step.md
   • doc/site/how-to-*
3. test
   • make unittest
   • make functest
   • make haddocktest
4. branch
   • switch to release branch (git checkout X.Y)
5. version
   • edit .version (don't make setversion)
   • manually bump version for affected package(s): cabal files, manual..
6. package
   • set Makefile's PACKAGES to affected package(s)
   • make cabalsdist
7. test
   • install from tarball(s) into a clean directory
8. tag
   • make tagrelease
9. push
   • git push --tags
10. upload
    • make cabalupload
11. announce
    • [email hledger]
    • [tweet]

Implementation notes

hledger

There are two core cabal packages:

hledger-lib - data model, parsing, manipulation, standard reports (github)
hledger - command line interface, reusable cli options & helpers (github)

Most data types are defined in hledger-lib:Hledger.Data.Types, while functions that operate on them are defined in hledger-lib:Hledger.Data.TYPENAME. Here's a diagram of the main data model:

hledger parses the journal file into a Journal, which contains a list of Transactions, each containing multiple Postings of some MixedAmount (multiple single-Commodity Amounts) to some AccountName. Commands get and render Reports from the Journal, or sometimes from a Ledger, which contains Accounts representing the summed balances and other details of each account.

After surveying the packages, modules, and data types, try tracing the execution of a hledger command:

1. CLI stuff is in hledger:Hledger.Cli.
2. hledger:Hledger.Cli.Main:main parses the command line to select a command, then
3. gives it to hledger:Hledger.Cli.Utils:withJournalDo, which runs it after doing all the initial parsing.
4. Parsing code is under hledger-lib:Hledger.Read, eg the hledger-lib:Hledger.Read.JournalReader.
5. Commands extract useful information from the parsed data model using hledger-lib:Hledger.Reports, and
6. render it to the console.
7. Everything uses the types and data utilities under hledger-lib:Hledger.Data, and the general helpers from hledger-lib:Hledger.Utils and below.

hledger-web

hledger-web is in a third cabal package:

hledger-web - web interface (github)

It is a single-executable web application using the yesod framework. It runs a built-in web server serving some views of the journal file, reading it at startup and again whenever it changes. It can also append new transactions to the journal file. There are two main views, which can be filtered with query arguments:

• /journal, showing general journal entries (like hledger print)

• /register, showing transactions affecting an account (slightly different from hledger register, which shows postings).

There is also:

• a sidebar (toggled by pressing s) showing the chart of accounts (like hledger balance)
• an add form for adding new transactions (press a)
• a help dialog showing quick help and keybindings (press h or click ?)

Most of the action is in

• config/routes
• templates/default-layout-wrapper.hamlet
• Foundation
• Handler.*
• static/hledger.js
• static/hledger.css

Handler module and function names end with R, like the Yesod-generated route type they deal with.

Dynamically generated page content is mostly inline hamlet. Lucius/Julius files and widgets generally are not used, except for the default layout.

The quickest way to test changes is make ghciweb, :main --serve, control-C, :r, repeat. No linking is required, and changes to static files like hledger.js are visible after reloading a page.

Another way is yesod devel, which rebuilds automatically when files change, including config files, templates and static files (but only in the hledger-web package).

A third way is make autoweb, if you can get it working (see the makefile for instructions). This rebuilds automatically when haskell files change in any of the hledger{-lib,,-web} packages.