On Mon, Jun 10, 2024 at 3:15 PM Lover O'Bean <[email protected]> wrote:
> > 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" > We'll sort this out. I'll release the master as 3.0 and whatever's next is going to live on a branch until it's ready. > - 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. > That's even more confusing to me. Only having readily-released stuff on numbered branches makes things obvious. If it's numbered it's official, and you should want the highest number. In fact, maybe nobody needs to know about the C++ branch unless they're coding on it, or if/when it becomes the new new thing. (I should have done it that way in the first place but at the time I had enough velocity I thought I'd get it done quickly.) > 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. > It would only be optional and what's more, at the edges, that is, quickly translated from the input, and only reapplied at the output (and one and/or the other). Little development time involved IMHO. 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 > <https://groups.google.com/d/msgid/beancount/82c16415-d849-4a3e-bb02-10d741bf29a5n%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%2BhMsCHOH49LgcLzDcnHFhRqhnMyjfcdiBBrYypmeVxEGPQ%40mail.gmail.com.
