Maintenance status of ofxparse

[mxdev88]

Hi,

First, thank you for creating and maintaining ofxparse. It remains one of the few Python libraries for parsing OFX files and is still used by a number of downstream projects.

I noticed that repository activity appears to have slowed down, with a number of open issues and pull requests remaining unresolved. Before adopting the library for a new project, I wanted to better understand its current status.

Could you clarify whether:

• Is the project still actively maintained?
• Are bug fixes and pull requests still being reviewed and merged?
• Are there plans for future releases?
• If active maintenance is no longer possible, would you be open to adding additional maintainers or transferring ownership to interested contributors?

Having some clarity on the maintenance status would help users and downstream projects make informed decisions about depending on ofxparse.

Thanks again for your work, and I appreciate any update you can provide.

[DylanMerigaud]

Not the maintainer, just someone who has spent time in this parser recently. Here is what is on
the public record, so you can decide without waiting.

• Last commit to master: 2021-05-31. Last release: 0.21, the same day. The one before that was
  0.20 in December 2018.
• 33 open issues, 10 open pull requests, and the repository is not archived.
• The tracker is quiet but it is not a void: jseutter answered on XMLParsedAsHTMLWarning #170 as recently as 2023, and
  on UTF-8 Encoding #133 he reviewed and approved a contributor's patch in 2021. The pattern looks more like a
  maintainer with no time than one who has walked away, so your fourth question is worth asking
  rather than assuming the answer.

For the decision you actually have to make: if you need something maintained today,
ofxtools shipped 1.1.1 in June 2026, after a quiet
stretch of its own (nothing on PyPI between January 2022 and June 2026), but it is moving now.
It reads OFX and QFX, and its API is quite different from ofxparse's (an ElementTree style parse
and convert rather than OfxParser.parse), so it is a port and not a drop-in.

If you stay on ofxparse, the practical risk is not that it stops working, it is that known bugs
stay unfixed. The one to check first is #133, and only if your files are OFX 2.x (XML) and can
contain non-ASCII: those raise UnicodeDecodeError on ASCII, because the header reader stops at
the first < and an XML document has no key: value header block for it to find. It does not
fire on 1.x SGML files, I checked. That issue is also a fair illustration of the state of things:
a fix was proposed in 2021 and approved by @jseutter, and the pull request was never filed.

[DylanMerigaud]

@mxdev88 asked whether pull requests still get reviewed and merged. Rather than guess, I applied
all ten open ones to master and ran them. Posting the results since they answer that question
with data, and they might save whoever picks this up some time.

All ten still apply cleanly, which is unsurprising: nothing has landed since May 2021, so there
is nothing to conflict with. Six are bug fixes whose bug I could still reproduce on master today.

Worth knowing first: three of them fix the same bug, and the oldest is the only one that does
not regress.

#160, #161 and #179 all fix read_headers() treating a leading blank line as end of headers.
#161 and #179 are the same one-character change (break to continue), four years apart. #160
also swaps line.split(b':') for partition, and that turns out to matter:

header block followed by	master	#160	#161	#179
nothing unusual	9 headers	9	9	9
a leading blank line	0 headers	9	9	9
a non-blank line with no colon	9 headers	9	ValueError	ValueError

So #160 looks like the one to take, and the other two can close as duplicates. All three share a
smaller wart: a junk line that does contain a colon gets absorbed as a header.

The other bug fixes, each checked against a real anonymised bank file carrying that exact
quirk:

• Fixing parse error "unknown encoding: cpNONE" #163, cpNONE. handle_encoding builds a codec name with "cp%s" % cp, and NONE is a
  legal CHARSET value in OFX 1.x. An E*TRADE file dies with
  LookupError: unknown encoding: cpNONE on master and parses with the PR. This also closes
  OfxParser.parse fails: unknown encoding: cpNONE #154 and Bug with encoding for ETrade #171. It special-cases the literal string NONE rather than validating the value, so
  any other unexpected charset still builds a bogus codec name, but it fixes what people hit.
• The header in a Wells Fargo .qfx file contains no newlines #172, a Wells Fargo header with no newlines. ValueError: too many values to unpack on
  master, parses with the PR. No test in it, so the suite would not notice if it regressed.
• Handle chknum in transaction field #173, CHKNUM where the spec says CHECKNUM. Master returns '' for the check number
  and the PR returns 1932. Silent data loss rather than a crash, which arguably makes it the
  worst of the six. Its loop has no break, so a file carrying both tags would let the
  non-standard one win.

Housekeeping:

• Remove bs4 deprecation warnings #181 removes the bs4 deprecation warnings, and there are a lot: a 67-test run emits 539 on
  bs4 4.15. Two things to fix first. warnings.filterwarnings(...) inside soup_maker mutates
  the process-wide filter list, so after one OfxParser.parse() the caller's own unrelated
  BeautifulSoup calls stop warning too (I checked warnings.filters: empty before, carrying an
  ignore entry after). with warnings.catch_warnings(): around the constructor fixes it. And
  from bs4 import XMLParsedAsHTMLWarning needs beautifulsoup4>=4.11 declared in setup.py,
  since on an older bs4 every parse() raises ImportError.
• trim usage of six #177 trims six. Fast-forwards, suite identical before and after.

Would not merge as they stand:

• Add writer of Credit Card Statement #175, the credit card writer. The writer part is a genuine fix (master rewrites a credit
  card statement as a bank account), but it is bundled with a Signon change that calls
  .strip() on dtserver, which is None when the tag is absent, so it breaks parsing for
  files that are fine today.
• Generic ofx2dataframe converter capable of handling multiple inputs #144 takes the suite from 67 passed to zero collected: it adds an unconditional
  import pandas inside the shipped package, with pandas declared in neither setup.py nor
  requirements.txt.

Nothing needed from me here, this is just legwork. Happy to re-run any of it or to split
anything out.