Open pp-mo opened 2 months ago
The antlr runtime is pure python. Is the objective to be able to re-generate the parser with pure Python? This seems like a lot of work for not much benefit.
I see the fundamental concern with pinning to a specific version of antlr runtime - my guess is that we could support a version range, but I don't really know the compatibility guarantees of antlr. This will be the same problem for all users of the antlr runtime - perhaps we can follow the same approach used there (after all, ANTLR is popular).
FWIW the testing of the parser is extensive. I have confidence that if the tests pass, the runtime is fine. Perhaps then the antlr runtime can be bumped through dependabot frequently?
Is the objective to be able to re-generate the parser with pure Python? This seems like a lot of work for not much benefit.
Yes but, to be clear, our major driver for this is the ongoing cost of maintaining the extra-python components, i.e. Cython and the resulting complicated build and installation mechanisms.
And the majority of that cost, I would say, is not down to essential complexity of the work, but just because we lack the relevant expertise. Our experience in the current sprint certainly highlights that : apparently simple fixes are taking hours+hours of head-scratching, because we are all working with tools and techniques we don't understand in any depth.
There's a serious question here as to whether building our own solution could have similar problems, with tools such as a language parser being equally outside the experience of most of the team. But I'm hopeful that those parts would not change much and won't require much ongoing effort.
Relates to #423 - well, it would render that unnecessary I suppose. Would perhaps be part of the solution to having a pure-python cf-units - see #446