On Fri, Feb 12, 2021 at 12:00 PM kuba....@gmail.com <kuba.ja...@gmail.com> wrote:
> Hi all, > > I'd like to unpack the comment from Dan regarding additions to the CSV > importer > > > > > > *Also, if anything, I expect the CSV importer in beangulp to > becomesimpler, and not to gain new features. It was intended as an example > todemonstrate how to write an importer and grow into something with a > knowfor every aspect, and it deviated from its original scope.* > *https://groups.google.com/g/beancount/c/YhBQEh7xVdk > <https://groups.google.com/g/beancount/c/YhBQEh7xVdk>* > > So is there a definite plan to remove functionality, or in fact the CSV > importer from bean gulp moving forward? > > The feature I would like to add is the support for a currency column as I > have some transactions from PayPal that are in multiple currencies which at > the moment all come out as my default currency. > > But I would like to understand whether I should be putting my effort into > the beangulp importer or whether it would make more sense for me to create > my own CSV importer moving forward. > It's unclear. I built a CSV importer as an example - that was the original purpose - and then I started using it, and since it works, well, more people started using it, and now it's a thing and it has a bunch of options. But it's a thing without unit testing. I don't feel enthralled about supporting code without tests on my off time. I'm not even sure all the options are compatible with each other. So in beangulp we should either a) clearly mark it as an example and make it as lame as possible (so that nearly everyone would want not to use it), or b) blanket it with unit tests specifically crafted for all the myriad options it has grown to accept over time and commit to supporting it. I think (b) would be favored, but it requires a moderate amount of work. The ultimate CSV importer is something that could totally live within Beangulp, or even acquire its own repo (no strong preference there). I imagine a better CSV importer, one that automatically and intelligently sniff out the semantics of columns in the majority of cases and produce a Beancount file without any configuration, but that is also explicitly configurable if desired. In fact, the sniffing code should be its own library, and it should also be reused for importing Google Sheets spreadsheets, which are so incredibly useful for collaboration with other people unfamiliar with Beancount (they can input postings in there). I think the OFX example should eventually migrate outside or be deleted. In any case, Beangulp will not grow to include various random importers; I tried that a long time ago (LedgerHub) and there wasn't enough interest. It's also not clear how much reuse between users there is. I think we could create a repo like that, with an incredibly liberal PR acceptance policy, but the problem is that the easiest testing requires user files, so it'll become implicitly broken by nature. So perhaps many individual importers living in various repos is best. It would be nice if we can create a unique tag so that they're easy to find, e.g., if you're looking for an existing importer for a particular bank and what-not, or a registry somewhere (a file in Beangulp? A Google Doc with a list?). -- 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 beancount+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOok9XxZKZepaUU1Wov049q6%2B7w-DsAt_T1v_s1xwfBVw%40mail.gmail.com.
