+1 on all points
On Mon, May 20, 2024, 17:04 Daniele Nicolodi <[email protected]> wrote: > beangulp is a redesign of the old importers code in Beancount v2. The > main goal of the project has always been to define a API for importers > and to build a minimal framework around it that implements most of the > tedious parts. > > The common importers API should have enabled importers to be easily > shared and used in import applications implementing additional features > on top or simply implementing a specific workflow. > > Judging from the overwhelming lack of feedback we received, I thing that > the goal has not been met. > > On the other hand, implementing an importer is so simple that I am not > surprised that there are multiple projects dealing with importing > transactions into a Beancount ledger. > > Personally I use beangulp with some extra functionality bolted on top to > do automatic categorization and some cleanup of the imported > transactions. I use Emacs and some personal tools built on top of > beancount-mode for reviewing the imported transactions. I would never > use a browser based solution because it would always be too slow > compared to working directly in Emacs. > > Cheers, > Dan > > > On 20/05/24 20:59, Timothy Jesionowski wrote: > > So now I'm wondering, since I've got a handful of purely custom > > importers and a whole bunch of new importers to write next quarter, what > > does the preponderance of the community use and why? I've heard of Red's > > importers, beancount-import, and now beangulp. I know there's others. I > > haven't looked at any of them personally yet because I'll need to > > package them for my niche linux distro first (NixOS has /some > downsides/). > > > > Just looking at the github repos: > > > > 1. beangulp was written by the same guy that wrote beancount itself (Hi > > Martin!) so I would expect it to integrate very well. > > 2. beancount-import has a web UI, which seems like a very useful tool > > for verifying all this automation (especially for expense > > categorization, which I'm skeptical can /ever/ be particularly > reliable) > > 3. red's importers has the most active community by far, and seems to > > focus heavily on a "run the script every time you look at the > > reports" workflow > > > > I don't have unit tests on my importers, and I'm importing from CSV's > > because I just got the simplest thing working. It's a KISS > > <https://en.wikipedia.org/wiki/KISS_principle> setup that's exactly as > > messy as it sounds. So given that I need to do an overhaul anyways, I'm > > curious why, for example, James doesn't use red's scripts. > > > > Is it just that a fully automated setup is harder to build? The peace of > > mind from looking at the web UI to verify stuff? > > > > Sincerely, > > Timothy Jesionowski > > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/9f551ccd-4182-4a94-a8a2-31ab19f0f870%40grinta.net > . > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPXZCwvDEqQh-Fm9Fh%3Df9uVnba44zg92cKLDsAaYwV3Ag%40mail.gmail.com.
