On 12/02/2021 18:41, Martin Blais wrote: > On Fri, Feb 12, 2021 at 12:00 PM [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> 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 become > simpler, and not to gain new features. It was intended as an example to > demonstrate how to write an importer and grow into something with a know > for 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.
I think it is a worthy addition. > 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). As Martin wrote, there are no concrete plans. I am not very familiar with the code, but the current scheme of things is hard to maintain and to use: in the couple of occasions that I had to roll an importer from a CSV-style input files I found it easier to write one from scratch using the csv module than to understand the gazilions of options of the CVS importer. I think it would be much better if the CSV importer would become a base class for people to build their importers upon via subclassing. In this way the parameter space that would need to be tested could be drastically reduced. There are many other things I would like to work on before this, thus, unless someone else does pick up the job, don't expect progress on this any time soon. Cheers, Dan -- 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/c38d1146-c9cd-09d9-c1b9-9463d5a85c0f%40grinta.net.
