Our own AEB43 parser

Organisation
1

Following account_statement_aeb43 fails with Python 3.12 (#12811) · Issues · Tryton / Tryton · GitLab I reviewed a little bit the code of csb43 package. The package does not seem to be actively maintained. But I found also the code quite complex and difficult to understand. Also it does much more than what we need.

I though I could write a simpler parser based on https://downloads.tryton.org/standards/aeb43.pdf
So here is Tryton / aeb43 · GitLab which is less than 200 lines.
It will be great to have some testing feedback before doing a first release.

I plan to update the module account_statement_aeb43 to use it for the next series.
If the fix for account_statement_aeb43 fails with Python 3.12 (#12811) · Issues · Tryton / Tryton · GitLab is not published fast enough, I think I will add setuptools as dependency for our module.

1 Like
2

Of course, because the library format did not change for 10 years, so I do not think you must expect a lot of changes in a parser of a format which is already fixed. Same happens for coda and mt940 which did not receive any change for more than our year (from sept 2021 to March 2023). Last change of csb43 package was on October 2022, just a year and two months ago.

Having said that I do not understand what is the problem with tests. Why is the code now failing for python 3.12? The code already worked for the 7.0 series release where we added support for python 3.12 and it was already tested.

Reading the test log I see the problem is:

FileNotFoundError: No such file or directory: 'account_statement_aeb43/tryton.cfg'

Which seems compltetly unrelated to the parser library used.

I’m concerned about such rewrite of the parser because there are now three libraries to parse such files:

So instead of sharing efforts we are just reinverting the wheel :man_shrugging: :man_shrugging: For me this is against of the objective of open source software.

3

I think it’s a wrong fallback in the setup.py when a depends is missing. I already had the same error message and it was because a package was not installed in my environment.

4

You are right, but what I’m pointing is that I did not understand how we ended writing a new parser for aeb43 following this error which is unrelated to the parser.

I think it is important to understand the root of the problem before taking any action, which it seems we are already late

5

External dependencies are a pain for maintenance, especially small libraries.
They force us to proxy maintain them in some case (and have to deal with non interesting parts) or they block us in the upgrade processes.

So basically I want to reduce as much possible our dependencies.

6

Your proposed fix is just 6 lines of code instead of newly 200 lines to maintain. :thinking:

Also, the library never had been blocking, but on the other hand all changes where included and released.

We are on some holidays, I do not think we can assume any maintainer to review a MR in just 4 days in such period (nor or normal days).

Then just include the parser as part of module instead of creating a new dependency which you will need to maintain. Other software can just reuse the existing libraries.

7

And it was simpler to write a parser.

I’m free to choose what ever I want to maintain.
The internal dependency of the Tryton project are not the dependencies that create troubles.

8

Of course you are free to do whatever you want.

For me it is clear that is has been some time that you are already going alone in this boat without wanting anyone else to join. I’m not blamining you for that but I’m not feeling confortable in this situation. :cry:

9

The fix has been released in version 0.9.3: