Is there a language-neutral intermediate representation for a beancount ledger?

[Filip Filmar]

Hi.

Perhaps this is a wrong-headed idea from the get go. I apologize if so.

As asked in the subject - is there a language neutral IR for the ledger, that isn't the freeform text format? I ask because I'd rather use a different programming language for any beancount extensions. https://github.com/beancount/beancount/blob/master/beancount/cparser/ledger.proto is kind of that, except it does not preserve the include structure as far as I can tell.

One reason is I'm not that skilled with python. Another is that last time I checked beancount pulls in a preposterous amount of python deps, each one a potential dependency hell. This is of course not beancount's fault, but it is something I worry about.

Thanks,
F

[Martin Blais]

Yes, the ledger.proto including the data.proto from ccore is supposed to be that.

Indeed it doesn't currently represent comments but a while ago it was discussed to be able to do that, and to allow programmatic transformation on the parsed output and to reconstitute text, as well as round-tripping.

It's never been done, but IIRC it was the next project on the cparser front.

I spent a good amount of time dealing with zero-copy C++ protos from Python and it wasn't obvious and more or less gave up.

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. A few people have written decent Rust parser for the full Beancount syntax BTW.

--
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 beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAKaOXii_goRTnyCQyvKDms944S0dGT0i3C2%2BHOEpVSRU08u2dQ%40mail.gmail.com.

[Stefano Zacchiroli]

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.

Cheers
--
Stefano Zacchiroli . za...@upsilon.cc . https://upsilon.cc/zack _. ^ ._
Full professor of Computer Science o o o \/|V|\/
Télécom Paris, Polytechnic Institute of Paris o o o </> <\>
Co-founder & CTO Software Heritage o o o o /\|^|/\
https://twitter.com/zacchiro . https://mastodon.xyz/@zacchiro '" V "'

[Daniele Nicolodi]

On 10/06/24 00:52, Filip Filmar wrote:
> One reason is I'm not that skilled with python. Another is that last
> time I checked beancount pulls in a preposterous amount of python deps,
> each one a potential dependency hell.

beancount version 2.3.x pulls is quite a few dependencies that are used
only for utility scripts. These are not commonly used and thus have been
moved to a dedicated project. beancount from the master branch IIRC
depends only on click, dateutil, and regex, with very relaxed version
requirements. Of these, only dateutil introduces a transitive dependency
on six.

TL;DR: if you want minimal dependencies, install beancount from the git
master branch:

python -m pip install git+https://github.com/beancount/beancount.git

Cheers,
Dan

[Daniele Nicolodi]

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

[Stefano Zacchiroli]

On Mon, Jun 10, 2024 at 11:04:11AM +0200, Daniele Nicolodi wrote:
> - 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?

How about Fava?

As I understand it, Fava is currently incompatible with beanquery as a
separate project, or at least I'm regularly getting syntax errors(!)
when executing within Fava queries that work fine with beanquery (split
out) and beancount 2.x.

Maybe your lower profile plan for a beancount 3.0 release (which I like
a lot) can help with that too.

[Daniele Nicolodi]

On 10/06/24 11:33, Stefano Zacchiroli wrote:
> On Mon, Jun 10, 2024 at 11:04:11AM +0200, Daniele Nicolodi wrote:
>> - 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?
>
> How about Fava?

I hope the Fava maintainers will make Fave compatible with beancount
3.0.0 once we release it. I don't use Fava and I'm not familiar with its
implementation.

> As I understand it, Fava is currently incompatible with beanquery as a
> separate project, or at least I'm regularly getting syntax errors(!)
> when executing within Fava queries that work fine with beanquery (split
> out) and beancount 2.x.

I don't know how Fava integrates BQL queries. I suspect that it imports
beancount.query and uses the API. Therefore, instlling beanquery
alongside beancount 2.x does not make Fava use it as beanquery does not
install anything in the beancount namespace.

> Maybe your lower profile plan for a beancount 3.0 release (which I like
> a lot) can help with that too.

I think a beanquery release would be sufficient for this. Fava could
then either depend on beanquery (and use the nicer beanquery API) or
could try to import beanquery and fall back to beancount.query, allowing
users that install beanquery to use the new features.

I'll try to have a beanquery release out this week.

Cheers,
Dan

[Stefano Zacchiroli]

On Mon, Jun 10, 2024 at 12:19:22PM +0200, Daniele Nicolodi wrote:
> I hope the Fava maintainers will make Fave compatible with beancount
> 3.0.0 once we release it. I don't use Fava and I'm not familiar with
> its implementation.

To my surprise, I couldn't find any Fava issue discussing the
incompatibility, so I've just filed one here:
https://github.com/beancount/fava/issues/1824 (Cc:-ing you). We can
discuss the specific issue with the Fava maintainers there; they are
usually quite reactive.

[Chary Chary]

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).

[Martin Blais]

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.

--
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 beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/3ac4293f-66c0-4176-b91b-d4bed6d059dfn%40googlegroups.com.

[Chary Chary]

- 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.

Martin,

your documentation for beancount is definately a blueprint for project documentation.

But for beanquery, can we then at least spin off the new version of a document from the current one, the new version shall be applicable for a new standalone version of beanquery

And then probably a policy can be introduce to always update a document in a draft mode, when submitting a pull request? 

[Martin Blais]

+1 SGTM let's try it

My focus is the core beancount anyhow, spinning off parts was a way to keep things under a certain size and let people experiment.

Let's see how this goes,

--
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 beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/35ab2f6f-4720-4433-99cb-7a65c041e65bn%40googlegroups.com.

[A I]

> 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. A few people have written decent Rust parser for the full Beancount syntax BTW.

I would love to contribute to beancount v3 in Rust. Count me in!

[Daniele Nicolodi]

On 10/06/24 17:11, Chary Chary wrote:
> And then probably a policy can be introduce to always update a document
> in a draft mode, when submitting a pull request?

I don't really know how to respond to requests like this.

~/src/beanquery$ git log --format='%ae' | grep char...@gmail.com
~/src/beanquery$

~/src/beancount$ git log --format='%ae' | grep char...@gmail.com
~/src/beancount$

AFAICT you haven't contributed to beancount or beanquery yet you are
asking to introduce policies to govern the contributions of others. This
is one step beyond anything I've see so far.

This is something that I bumped into recent and may be worth reading

https://www.hezmatt.org/~mpalmer/blog/2024/05/14/is-this-project-still-maintained.html


Cheers,
Dan

[Lover O'Bean]

> 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.

[Chary Chary]

On Monday, June 10, 2024 at 8:49:45 PM UTC+2 dan...@grinta.net wrote:

AFAICT you haven't contributed to beancount or beanquery yet you are
asking to introduce policies to govern the contributions of others. This
is one step beyond anything I've see so far.

This is something that I bumped into recent and may be worth reading

https://www.hezmatt.org/~mpalmer/blog/2024/05/14/is-this-project-still-maintained.html

Cheers,
Dan

Sorry if I offended you somehow, as I really appreciate the work you are doing in developing beanquery and beancount further.

I actually did make a small PR to beancount. ( I have a different name in github, sorry for confusion).

My suggestion to make documentation to be a part of PR / commit is coming from my experience in contributing to python itself, which is known for its good documentation. 

And I thought I may suggest (not ask) to use this practice  in beancount as well.

Martin has laid really great foundation in relation to documentation, there are lots and lots of man hours there. 

I think most of the users of beancount would not be around without this documentation.

I am sure most of users will feel sorry if the documentation will slowly decay, from the other side will also be happy to work on contributing to it.  

Hence, my suggestions.

Once again, thank you very much for maintaining beanquery

 

[Martin Blais]

On Mon, Jun 10, 2024 at 3:15 PM Lover O'Bean <lover...@gmail.com> 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/82c16415-d849-4a3e-bb02-10d741bf29a5n%40googlegroups.com.

[Martin Blais]

One of the problems with switching that makes me really skittish about even trying it is that there's no going back.

You can't easily convert back to GDocs.

--
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 beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/35ab2f6f-4720-4433-99cb-7a65c041e65bn%40googlegroups.com.

[Lover O'Bean]

On Monday, June 10, 2024 at 9:33:23 PM UTC-4 wrote:

 

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.

The development time may be small, but the additional burden on community support and on users is large and recurring forever.  Much documentation will need to have two versions, one for each mode, and when someone wants to discuss a question like "How do I handle mileage reimbursement from my employer," discussion will be much less productive as some people forget to explicitly state which convention they are using.

It seems like it could easily become a "Second System" quagmire from a support and usability standpoint, and I think that "Worse is Better" would serve the community in the long term.

[Daniele Nicolodi]

On 10/06/24 23:58, Chary Chary wrote:
>
>
> On Monday, June 10, 2024 at 8:49:45 PM UTC+2 dan...@grinta.net wrote:
>
>
> AFAICT you haven't contributed to beancount or beanquery yet you are
> asking to introduce policies to govern the contributions of others.
> This
> is one step beyond anything I've see so far.
>
> This is something that I bumped into recent and may be worth reading
>
> https://www.hezmatt.org/~mpalmer/blog/2024/05/14/is-this-project-still-maintained.html
>
> Cheers,
> Dan
>
>
> Sorry if I offended you somehow, as I really appreciate the work you are
> doing in developing beanquery and beancount further.

No offense taken. It is perfectly fine for you to dictate how I
contribute to open source projects. I guess you didn't bother reading
the blog post I liked to.

I'm really sorry for the inconvenience I've caused to you releasing my
work under an open source license. Any further development will happen
in a private branch, so that you will not have to suffer similar
discomfort again.

[Martin Blais]

On Mon, Jun 17, 2024, 09:33 Daniele Nicolodi <dan...@grinta.net> wrote:

On 10/06/24 23:58, Chary Chary wrote:
>
>
> On Monday, June 10, 2024 at 8:49:45 PM UTC+2 dan...@grinta.net wrote:
>
>
>     AFAICT you haven't contributed to beancount or beanquery yet you are
>     asking to introduce policies to govern the contributions of others.
>     This
>     is one step beyond anything I've see so far.
>
>     This is something that I bumped into recent and may be worth reading
>
>     https://www.hezmatt.org/~mpalmer/blog/2024/05/14/is-this-project-still-maintained.html
>
>     Cheers,
>     Dan
>
>
> Sorry if I offended you somehow, as I really appreciate the work you are
> doing in developing beanquery and beancount further.

No offense taken. It is perfectly fine for you to dictate how I
contribute to open source projects. I guess you didn't bother reading
the blog post I liked to.

That's a pretty good opinion piece that blog!

Spot on

I'm really sorry for the inconvenience I've caused to you releasing my
work under an open source license. Any further development will happen
in a private branch, so that you will not have to suffer similar
discomfort again.

I think you mean to be snarky.  That might be lost on some people, it's worth noting.

(Your tone can be misleading at times and some may take it harshly.)

--
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 beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/563cb594-910d-45c9-8450-057c759bf390%40grinta.net.

[Lover O'Bean]

I support Dan!