Like beancount, just worse

04dd9ec Add a "why" section to the README

~cfcosta pushed to ~cfcosta/hortela git

1 year, 17 days ago
1 year, 17 days ago


There's not much to see here right now. At some point, it will be beancount, but better in some ways and worse in others. The decision is going to be yours.


In some ways this is a teaching project, the idea was to learn more about double-entry accounting, and how to apply it correctly. Beancount is a great tool, but it's constructs do not exactly match the theory, and you have to wrangle a little bit to "prepare" your data for an accountant.

Beyond that, other tools like YNAB are really, really good, and I think by doing a new grammar, we can integrate some of those concepts (like budget) envelopes in a really nice way.

One last point is that Apache Arrow and Polars are extremely flexible tools, and by leveraging them we can do much more complex analysis beyond what it is possible with the default beancount SQL dialect.

#Getting help

Hit us up at ~cfcosta/hortela-discuss@lists.sr.ht, and we might be able to help :)


To contribute, you just need to send your patches to ~cfcosta/hortela-devel@lists.sr.ht. There's documentation on how to do that on git-send-email.io.

We require that all contributions are signed off by you, and by doing so, that you accept the Developer Certificate of Origin. This does not exclude any of your freedoms, just guarantee that, to the best of your knowledge, your contribution is in accordance with the MIT license.

To do that, you can set git to sign it off automatically on each patch:

git config format.signOff yes

You might need to annotate your e-mails with more comments and explanation, you can do that automatically by setting:

git config --global sendemail.annotate yes

Also, the subject prefix needs to be set so the CI knows which repo to build.

git config format.subjectPrefix "PATCH hortela"

Then, send to us your patch:

git send-email HEAD^

Add a description, and there you go! Someone will take a look at it, add comments and reviews, and eventualy, merge them!

Usually, we don't reject any patches, but we require at least this:

  • The explanation and the code makes sense.
  • The code is not visibly wrong (sometimes things slip through the cracks, its ok).
  • The tests and build pass (we want to be able to bisect easily, so all patches should be complete by themselves).
  • It's not completely unrelated or malicious.

For bugfixes, we try to add regression tests to all fixes. This is not 100% necessary, but it is extremely welcome.



Check LICENSE. We also require that contributors sign the DCO for their commits.

Nothing scary, if you do not agree with either of those or have some reservations, get in touch with us!

#Code of Conduct

We don't have a strict code of conduct, but if someone is behaving in a way that you feel is not correct or adequate, send me an e-mail.

We don't have social networks currently, just the mailing lists. Don't do anything you wouldn't do in a professional environment, and you should be fine.