Gosh, this thread. All at once: Stefano: - There's no existential risk. Small community of dedicated users + 1000 quiet users of stable software.
- About a roadmap, it's old but it's still 100% relevant: https://docs.google.com/document/d/1qPdNXaz5zuDQ8M9uoZFyyFis7hA0G55BEfhWhrVBsfc/ https://docs.google.com/document/d/1H0UDD1cKenraIMe40PbdMgnqJdeqI6yKv0og51mXk-0/ - Here's a pinned issue: https://github.com/beancount/beancount/issues/829 - re. Fava: it should update itself. +1 w/ Daniele on that. Hopefully PyPI releases make that easy. Daniele: - +1 to everyone using the master branch for minimum deps - Re v2/v3, let's close this matter now: I can christen a v3 branch off of the master branch. It's been the new stable for a VLT anyhow. This is largely a non-event but for clarity. (v4 can be the rewrite? on a branch) - What's more, the C++ rewrite was fine BUT for the protos zero-copy issue. We have a really slick new parser. I'd been hoping zero-copy across Python/C++ would have been solved with changes in protobuf (and it might at this point for all I know, it's probably time for another look, and protos were undergoing a rewrite 3 years ago, but there's upb as an option) but in any case, in the meantime activity in the Python community has made it very clear that Rust is the new best friend for project core rewrites and that's probably the way it should go. - Re. evolutionary approach, doubtful it can be made to happen, but have little alternative. I can look at the design doc and see which parts can be broken out that could be done incrementally. (FWIW I'd already identified making the parser support comments and round-trip, but I think no one stepped up for that). - Re. bugs from v2 --> v3, it's just a merge. I've been doing merges semi-regularly. - +1 to bean{gulp,query,price} on PyPI. Call them 1.0.0 why not, this is stable, working software. - re. documentation: baking it into reST/Sphinx is going to result in less up-to-date docs. Years of people contributing fixes have made that clear to me (I can't write three words without a mistake and years after people were still submitting typo changes). Maybe though it's a thing whereby during its development it's sufficient but maintenance is harder? I doubt it'll solve a problem. The right person to say something with heft about this would be someone who... wrote a lot of documentation. I really don't like the resistance to Google Docs for political reasons I've seen in the past (socialists) and feel quite strongly about kicking back unless it's clearly made for technical reasons. - +1 to moving the C++ code to a "cpp" branch, though what we could do instead is move just the ccore and make the existing newer/better C++ cparser that produces protos create the Python directives directly (before interpolation/plugins). That would be a faster parser for free. I'm sort-of 50/50 on moving that to the "cpp" branch. Maybe that's easier (a Rust parser would replace it in a Rust implementation, but data.proto is something I aim to keep, and would generate code from it). - Bazel can move to cpp too. - re. import I like it, that's a feature that could be done incrementally. - re. changes in indentation compatibility: I don't think they're very important and could be included in 3.0. On Mon, Jun 10, 2024 at 8:46 AM Chary Chary <[email protected]> wrote: > Dan, > > I like the idea of moving documentation to eST and Sphynx or .md files, > at least for beanquery. > If we make documentation to be a part of the original source code and make > a policy that documentation shall always be updated when a new feature is > added (e.g. via PR), then this shall hopefully make sure documentation > stays up to date. > > I saw a lot of very nice features implemented in beanquery (thank you very > much for managing it), but documentation was never updated, which is really > pity. > I hope this can still be recovered, because one thing is to formally > describe new feature, explain the thinking behind it and how author > intended to use it. > Since beanquery by its nature is very flexible and very versatile, having > a good documentation is also very essential there. > Also, I think beanquery is one of the things, what makes beancount very > distinct from hledger and ledger, so having a good documentation shall help > to attract new people to the community. > > Regarding speed improvement in v3: my *.beancount file is 7.8 MB, contains > transactions from the last 20 years in 130k lines and speed was never a > problem to me, I personally can wait till Martin's retirement when he plans > to move it to Rust (of whatever new language he will want to play with by > that moment). > > On Monday, June 10, 2024 at 11:04:16 AM UTC+2 [email protected] wrote: > >> On 10/06/24 09:27, Stefano Zacchiroli wrote: >> > On Sun, Jun 09, 2024 at 07:45:22PM -0400, Martin Blais wrote: >> >> I'm hoping to restart v3 in Rust at some point and to maybe write a >> >> proto generator for a Rust-native data structure at that time. Well, >> >> you know, probably in retirement if I'm realistic, unless someone else >> >> does it. >> > >> > The current v2/v3 split is very bad for the Beancount community right >> > now. If there is an existential risk for this (amazing!) community, it >> > lies there. I can elaborate on why I think that's the case, but I'd >> > rather focus on positive/actionable stuff. It's great that you >> > acknowledge publicly you won't have the time to do it yourself in the >> > near future. But I don't feel anyone feels empowered right now to >> > proceed with the Rust re-implementation of v3 you suggest. I think it >> > needs to be advertised clearly that there is a need to do so and you, >> as >> > Beancount leader, approve of that plan. Maybe a ROADMAP document >> > somewhere, or a pinned issue on GitHub clearly saying so. It won't take >> > a lot of time, but would be really beneficial for the community. >> >> I also think that the v2/v3 situation is unfortunate and I have been >> thinking for a while about redefining the plans for a 3.0.0 release. >> >> v3 is intended to be the C++ core rewrite, but it seems that this will >> not happen any time soon, or ever. The reason for the C++ rewrite is >> mostly performance. The rewrite was seen as the occasion to clean up >> some long-standing issues that require important changes to the core. I >> think a more evolutionary approach could better match the available >> resources. >> >> I would be very happy if beancount 3.0.0 would simply become the release >> in which the "leaf" tools (beangulp, beanquery, beanprice, etc) are >> split into separate projects. The git master could be released more or >> less in the current status as beancount 3.0.0. >> >> There are a few things needed for this to happen: >> >> - Make sure that all bugs fixed in the v2 branch are also fixed in the >> master branch. This just requires going through the git log for the two >> branches. There should not be much in the v2 branch. >> >> - Release at least beangulp, beanquery, and benaprice on PyPI. I >> released beangulp recently. I'm planning to clean up some loose ends in >> beanquery and release a 0.1.0 version soon. beanprice probably needs >> some cleanups too. I can take care of that too, if there are no other >> volunteers. Is there any other component moved to other repositories >> that people use? >> >> - Update the documentation to reflect the current state. It is a bit of >> a longer term plan, but for beangulp and beanquery, my plan is to move >> the documentation to reST and Sphynx. I think it would make sense to >> have the beancount documentation in the same format. Using Google Docs >> as the master for the documentation was thought to enable easier >> contributions to the documentation. However, I don't see many of these. >> I think Sphynx is a much nicer way to produce the documentation and it >> would allow for easier inter-project references. >> >> - Do some cleanup in the project. Moving the C++ code to a dedicated >> branch, alongside the Bazel build definition is high on my list, simply >> because it is a source of confusion, and because it make the source >> distribution much larger. >> >> On the top of my head, there are two pull request against the master >> branch that would make sense to merge for a v3 release: replacing the >> current parser with the parser based on Re/Flex and the improved grammar >> from the C++ rewrite, and the re-implementation the 'import' directive >> to be a literal import rather than the more complex and much less >> intuitive thing it is now. >> >> The latter is a compatibility break (unless we introduce the new >> 'import' semantic under a new name, but that would not allow to get rid >> of the code implementing the current semantic, which would hold back >> some important simplification) thus it would be nice to have it for the >> 3.0.0 release. IIRC, the parser improvements make the handling of >> indentation stricter, thus are also a compatibility break. However less >> sever and it could be part of a 3.1.0 release. >> >> 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/3ac4293f-66c0-4176-b91b-d4bed6d059dfn%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/3ac4293f-66c0-4176-b91b-d4bed6d059dfn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAK21%2BhOqzY5cdNy5xOaqL80DAHAor0BTawCao02PtRJ8vf6B%2Bw%40mail.gmail.com.
