> Stefano: > - There's no existential risk. Small community of dedicated users + 1000 quiet users of stable software.
I would like to agree with Stefano and respectfully disagree. If communities do not grow, they tend to die, and I think that it is important occasionally for the leader of a project to try to forget what he knows and take the perspective of a new user. This project is definitely for technically sophisticated users, but in addition to the inherent challenges of setting up a chart of accounts and importers, it's *extremely* confusing to figure out which branch to use. A significant portion of the time that one would use for setting up accounts and importers is spent trying to make sense of frankly conflicting statements in documentation and forum posts: "v3 is not ready" / "v3 actually is almost complete" / "oh yeah, v3 won't do X, Y, and Z" > - 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) As another option, perhaps keep the rewirte (Bazel / C++ / ???) on v3 and create a new version, 4.0, which contains the 2.x core and the structural refactoring. That way there is no question about what is the latest recommended stable branch. Also, on the topic, a while ago someone proposed adding the option to use credits / debits from traditional accounting to the current positive/negative number system. I would like to recommend not doing it: aside from development time, it will significantly confuse and complicate learning, supporting, and even using the tool. As an example of the latter, I recently tried to prototype a complex situation involving reimbursements that I was trying to prototype in GnuCash: the flexibility of having multiple fundamental operating modes meant that the time that I spent on it was multiplied by number of modes. On Monday, June 10, 2024 at 10:14:02 AM UTC-4 [email protected] wrote: > 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/82c16415-d849-4a3e-bb02-10d741bf29a5n%40googlegroups.com.
