On 21/10/2022 18:32, Red S wrote:
> Is beangulp being maintained? And if so, how can I find out answers to
> the questions below?
I have been taking care of beangulp lately. However, you have very high
expectations regarding the response time to requests regarding an
unpublished open source package that cannot be met in the free time I
can allocate to work beangulp.
> Meanwhile, beangulp has several major blockers for me, all of which
> seem like regressions from the former beancount.ingest. See my other
> threads from this week:
> - dedupe is broken <
https://github.com/beancount/beangulp/issues/93>
> when specifying multiple input files. PR is here but not yet merged
> <
https://github.com/beancount/beangulp/pull/64>
beancount.ingest had the same exact issue. I haven't merged the patches
that I wrote because I haven't yet written the tests to demonstrate that
they work.
> - multiple importers on the same file
> <
https://groups.google.com/g/beancount/c/G-GhFeBLnO4/m/AKuLgYDPAQAJ>
> not supported
To make document archival easily predictable and idempotent, beangulp
assumes is that there is one and only one importer per file. I don't see
what advantage there is in splitting the code that handles one file into
multiple importers.
If you already have multiple importers, it is trivial to implement a
"multiplexer" importer that implements the identify(), account(),
date(), and filename() methods and that delegates the extract() method
to other importers instances.
> - PyPI releases
> <
https://groups.google.com/g/beancount/c/G-GhFeBLnO4/m/AKuLgYDPAQAJ>
> not available, meaning I can't move beancount_reds_importers
> <
https://github.com/redstreet/beancount_reds_importers> to beangulp,
> which I'd like to do
beangulp is not yet ready for a release. I thought that the lack of a
release would have been a strong enough warning to possible users to
expect rough edges. If beancount.ingest works for you there is no reason
for switching to beangulp.
Cheers,
Dan