Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
    Ioan Eugen Stan
    Well, I was curious of the project. What are your goals with it, do you want to grow the project? Stuff like that.
    Some background:
    I just discovered ledger and co and I'm quite interested in keeping my personal finances but also in developing stuff on top - personal and/or commercial.
    I'm more familiar with the Java ecosystem (not scala :( ) and also the license is business friendly.
    I also like the antlr grammar and the project in general.
    The things I don't like / worry me are the language and the fact there is no community around the project.
    Anyway, I started using the library in a Java project and I am missing some documentation but slowly moving things forward.
    are you willing to accept contributions to the project. For starters I have a spring boot java example - but I'm interested in your policy towards having other people contribute in your project.
    I like to spell out things for clarity: other developers come with their own experience, ideas and different way of doing things. Some people can work with this, some can't and don't do it.
    I would love to hear back from you. It would be nice to put the java example up there, I think it will help some people to get started.
    oh, and great job on the project :)
    Ioan Eugen Stan
    I like that there are a lot of tests, separation between API, core and cli. Love the antlr grammar and the focus on making it more machined friendly by simplification of the grammar. It's basically what I would have done in Java :) (maybe not that diligently on the tests)
    Ioan Eugen Stan
    To sumarise:
    • great work, I want to build on top of it
    • I would like to push some stuff upstream - please consider if you want it
    • What are your plans regarding the project?
    35V LG84
    Hi, Thank you for very nice and thoughtful feedback. I would definitely like to have contributions or co-operation with other projects. I will answer in more detail soon in few days, so you could better figure out what is the best and most feasible way from your perspective to proceed with Tackler.
    Ioan Eugen Stan
    thanks for the feedback. Well, from my experience I learned that it's best to focus on ones own itch first. Right now I'm focusing on learning the system and building my habits of keeping the journal. I'm going to use hledger for that because it has much better tooling at the moment. Tackler I'm planing to experiment and see where it goes. The first things I would work on is figuring out how to attract more people - and that merits a discussion.
    For one, I don't want to work alone in a project and have to maintain everything. My interests and availability change over time.
    I will push some examples on how to use it with Java - since this is going to attract a few users and from them maybe some contributors
    one thing that I do know is that the project should spell out a message like: WE ARE LOOKING FOR CONTRIBUTORS . Maybe spelled differently so as not to sound desperate :)
    looking forward to your feedback
    Ioan Eugen Stan
    another area of interest for me is to use quarkus to build self container CLI apps on top of Tackler - to offer an experience similar to hledger and company
    I wanted to play around with GraalVM and quarkus and this might be a good opportunity
    once we have the apps we can distribute them via flatpak / flathub to be easily installed in all linux distributions
    personally I use flatpak quite a lot and I find it refreshing for installing packages that are not yet part of distributions or evolve faster than Debian releases (which is what I am using)
    35V LG84

    Hi, here are some answers and comments to your comments and questions:

    The community of Tackler is next to non-existing, that's true. However Tackler is actually used based on OSS-repository statistics and stats are increasing over time. So there is some traction of it e.g. e257/accounting/tackler#2

    Tackler core itself is actually really small, few thousand lines of code, so with all the tests it should be fairly easy to take over it. Also used Scala code is pretty straightforward. These should provide some insurance against small community.

    It would be ok-ish to have some java code with Tackler, if reason is good and well justified. One example would be in-memory Git repository writer: GitDB On the other hand, Scala is really nice language and it's possible to move from Java to Scala in gentle way (I did that - Tackler isn't very die-hard Scala).

    Separate reporter and/or web-server project based on Tackler would be really cool thing to have. I have a prototype done with Play Framework for server side and scalajs-react + ScalaJS + Tackler Client API on client side. Sprint Boot is also an interesting option. At the moment I think it would make most sense to have the server as separate project, but that is not set in stone. As about languages, I won't accept Node.JS or heavily Javascript based solutions for Tackler, because of untyped nature of the Javascript. Same goes for Python.Python utilities are totally ok, but core functionality of Tackler can't be implemented with Python.

    If you could point worst places where documentation is lacking or provide patches, that would be really awesome.

    Easy requirements for contributions are that everything is signed-off (e.g. every single commit) and it would be really nice if you could also PGP sign commits. Please see CONTRIBUTING, it has some information.

    Then the more difficult and vague stuff about contributing:
    There are some reason why tackler exists in first place and some high level goals in README. At the moment aim of Tackler is to have really narrow focus, but that minimal feature set should be done extremely well and trustworthy.

    Also all features must be tested really well. This is unbreakable rule for Tackler. I won't accept any changes (my own or someone's else) if it degrades seriously test coverage. There might be exceptions if it's truly too difficult to test reasonably, but it should be exceptional situation.

    I also like to see Tackler developed DDD/TDD way, so that all features are defined to some extend first, as are test cases for those features. Please see list of TEPs, e.g.: TEP-1009 and TEP-1010

    Tackler's idea is to be minimal core and cli interface is "reference implementation" of those features of core, but not necessesary full CLI UI. For example, I have several applications where all kind of business domain specific filters are defined in shell script and fed to tackler via --api-filter-def as base64 armored ascii strings. But those filter combinations are not implemented as CLI options for above reason.

    On the other hand, if the idea is cool, then by all mean let's have it in the Tackler (e.g. accounting checksums and geo location).

    My plans for tackler are: It will be maintained and extended as needed. (ATM I have tag support on the pipeline). Tackler's README has some high level ideas for future. I typically work with Tackler during nothern hemisphere winter and not so much during summer. However, this winter has been exception. Tackler probably won't ever have as many options and features as ledger, hledger or beancount. And it won't have ledger-compatible format.

    GraalVM would be really cool. I have had it on my list, but haven't had time to take look of it.
    If you think it would make sense, we could create a separate, more relaxed repo for tackler examples, like jgit Cookbook
    Ioan Eugen Stan
    Hi, I think your points are valid and reasonable. If they are written down so that new people have a reference point it would be great.
    I like processes and some rules to go by - too much freedom is not good - things get side tracked.
    I don't have such strong opinion on JavaScript and node.js . I know they are not perfect but I find they do their job sometimes. Of course I would not use them in core except with some waivers :)
    For example, antlr has a JavaScript target that I would love to use and also expose the ledger format to JS world
    I have some experience with create-react-app
    Ioan Eugen Stan
    I also tend to favor tools with a bigger user base. I started learning Scala a few years back and tooling was missing and for me the language is very expressive but also dense. You can write a lot of stuff in a just a few characters and that is good for writing but bad for reading and understanding. In my experience you write code once and then read it multiple times.
    Anyway, I'm not here to change your mind or anything, just ranting a bit :)
    I think a lot of stuff that is not core can live outside the main repo - it will make testing out new things maybe a bit slower (it's always easier in the same repo but maybe with git subtree or submodule things can seem in the same place),
    Having them separate makes it easier to handle contributions and we can have different policies regarding tests and stuff
    core should be ~ 80%-90%+ covered with tests, in the UI things might not be that easy
    Ioan Eugen Stan
    I would like to take on some of the management/ documentation / community building part once we settle on some goals for the project, something like https://hledger.org/ROADMAP.html#milestones
    I like the hledger project organization / website - I thing it's a good model to have. They managed to cover most of the stuff a good project needs in their website. I also like this chart - It's very useful for getting an overview https://hledger.org/_static/images/data-model.png
    regarding the docs - I would love more examples on how to get things done - and what are the API concepts.
    I was looking for some java docs to find out how to put things together, where is the entry point.
    I ended up loking over the code - core and cli to figure stuff out
    Ioan Eugen Stan
    anyway, once I have some time I will push the sample on my repo and make a PR - so we can start a discussion
    again regarding the repos - in my experience having lots of repositories has the tendency of slowing things down and confusing people - it is a bit of a mental effort for people, including me
    I think a lot of things can be done as we go

    If you think it would make sense, we could create a separate, more relaxed repo for tackler examples, like jgit Cookbook

    I like this one, yes

    Ioan Eugen Stan
    some updates regarding what we discussed:
    • I've been learning more about how hledger works and double accounting in ledger style
    • I'm working on some code to convert a custom / multi line (ugly) transaction report from ING to ledger - going to publish that
    • I have a plan to convince the a client to use tackelr / ledger style accounting so I can spend more time on this
    • I've played around with typescript - to build a CLI (with oclif) and I'm quite pleased how that turned out very good - there is also antlr4 typescript project . Do you think we could compile the scala code to a typescript library as well ?
    Ioan Eugen Stan
    I'm working with a friend on an react app that will allow us to assign transactions exported from the bank to a list of accounts
    that will allow me to import with some manual work bank translations to the ledger format
    35V LG84

    Do you think we could compile the scala code to a typescript library as well ?

    I honestly don't know from technical point of view. From project's point of view, probably not. Tackler's core has few quite big java depencies which have non-trivial functionalities (e.g. JGit), so those might not translate to Typescript or Javascript so well. It would be also be a substantial amount of work to maintain core in two different implementation language, even when the translation would be done by compiler/plugins (all command line test, unit and integration tests would have to be duplicated for Typescript target).

    I'm working with a friend on an react app that will allow us to assign transactions exported from the bank to a list of accounts

    That sounds really cool. Especially if you have feedback how handy or not git storage backend is for your use case, that would be interesting to hear.

    Ioan Eugen Stan
    thanks, we are going to develop the app client side entierly - you copy paste /download the result locally - no server interaction yet
    it's a set of components for the future
    regarding the dependency on git, from your statement above, it does not seem to me that I can't OPT-OUT of git storage
    I do like the idea but I believe that storage / persistence should be plugable.
    while tackler library should not care where the data comes from, something like tackler-cli and tackler-web-api should care about that
    Ioan Eugen Stan
    hi, some updates: I've started learning clojure and I quite like it. I'm going to try to write some tooling around plaintextaccounting using it
    Eugen Stan
    This message was deleted