On Sat, Jul 4, 2020 at 6:09 AM Andre Engelbrecht <litt.fire...@gmail.com>
wrote:

> I specifically moved from ledger to beancount because:
>
>    1. Strictly defined directives, currencies and accounts
>
> Will not change, if anything it'll get stricter.


>
>    1. Python, and ability to easily extend with python
>
> Bindings will be provided as today. I'm hoping to be able to expose the
same or a very similar API.


>
>    1. Currency restrictions and currency related stuff
>
> Not sure what you mean (conversions at price?), but it should be the same.


>    1. Fava
>
> Another bonus was that it's simple to install with just pip.
>

Short of baking binaries for every single platform, that will become a bit
more difficult perhaps.
I think it's possible, these are details to be figured out later.

Beancount will still have a lot of Python involved, it's really just the
core part that I want to speed up, so ideally the whole core could be
wrapped up in an extension module (instead of just the parser).


I would prefer not needing to spin up a docker container and hassle with
> making it communicate over my network with other apps/plugins that might
> use
> it's API. It's an incredible barrier to entry for the non-developer. They
> already have to
> know how to use pypi and potentially struggle with the python path. Making
> them
> use docker now would be a bad move imo.
>

Docker will not be required; one should be able to build it locally and run
it from there, and package the resulting binaries.
That's more of a convenience than anything else; actually others will build
container support if they want to.


Hopefully this will be distributed as a binary, and simple way to "install"
> plugins.
>

As previously, I'll leave most of the packaging details to distribution
maintainers,.
For plugins, Python ones should be similar as before.
Faster plugins implemented in C++ will require to implement some support
for dlopen and an environment to build them, those details will be figured
out later. It should be possible (I don't see any particular reason it
wouldn't, especially since the data interface will be well specified via
protocol buffers). I suspect that many users with large ledgers will want
to convert some of their plugins to C++ to get the associated performance.



> *Disclosure*: I've converted a couple of people from using webapps or
> spreadsheets to
> use ledger. They love ledger despite some of the nuance. I've been trying
> to move them
> over to beancount, but having a bit harder time because of the python
> dependency.
> Fava and being able to run it locally has been a great driver to have
> people at least consider
> installing python and giving beancount a test run.
>

Installing Python is a pretty low bar IMHO...


I do hope with this update that distributing/installing beancount wouldn't
> get more complicated.
> We already had to deal with that in the frontend javascript world :D
>

I hear you. Bazel should provide a pretty stable build experience.



> On Saturday, 4 July 2020 10:45:23 UTC+1, Patrick Ruckstuhl wrote:
>>
>> Hi,
>>
>> I have to say I really like the vision and I see a lot of good ideas and
>> points in there.
>>
>> A couple of thoughts from my side.
>>
>> I think splitting this up into different projects will be helpful and
>> allow easier contributions. I think we should also have some "packaging" of
>> the different parts together as a "distribution" for "pure users" e.g. as a
>> docker container or maybe other formats.
>>
>> I see a danger of trying to do too much. If possible I would try to have
>> a smaller first step that converts over to the new architecture/project
>> setup and then tries to add new and additional features.
>>
>> Regards,
>> Patrick
>>
>> On July 4, 2020 8:34:35 AM GMT+02:00, Martin Blais <bl...@furius.ca>
>> wrote:
>>>
>>> Hi,
>>> Today I'm starting development on Beancount v3.
>>>
>>> This is going to be a pretty big change and will take a while.
>>> I've laid down the details in this document:
>>>
>>> https://docs.google.com/document/d/1qPdNXaz5zuDQ8M9uoZFyyFis7hA0G55BEfhWhrVBsfc/
>>> <https://docs.google.com/document/d/1qPdNXaz5zuDQ8M9uoZFyyFis7hA0G55BEfhWhrVBsfc/edit#>
>>>
>>> This file describes the new set of dependencies for it:
>>>
>>> https://docs.google.com/document/d/10R-msZljuqFY8nckUnR1jVxMX1ol7rJUCMZo7w7QUQs/
>>> <https://docs.google.com/document/d/10R-msZljuqFY8nckUnR1jVxMX1ol7rJUCMZo7w7QUQs/edit#>
>>>
>>> And there is a dedicated installation file for the in-development
>>> version:
>>>
>>> https://docs.google.com/document/d/1WwZYqsp28Uuk5eFqHQ1u1zqdjghymy8S_Yo-OJENoa4/
>>> <https://docs.google.com/document/d/1WwZYqsp28Uuk5eFqHQ1u1zqdjghymy8S_Yo-OJENoa4/edit#>
>>>
>>> The short version is that v3's core is going to be ported to C++ using a
>>> Bazel build, and the codebase will be sectioned between core and the rest.
>>> I just merged the new build definition in master.
>>>
>>> The current head will be branched as "v2" and maintained stable.
>>> It will build with both setup.py and Bazel.
>>> Backward compatible fixes to it will be done there and merged into v3.
>>> v3 development will occur on branch "master" and breaking changes will
>>> occur there.
>>>
>>> Comments appreciated (on the docs, or here if you prefer),
>>>
>>> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beancount/986ed772-bf70-4d29-89b9-109fc2d3dc28o%40googlegroups.com
> <https://groups.google.com/d/msgid/beancount/986ed772-bf70-4d29-89b9-109fc2d3dc28o%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 beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/CAK21%2BhP1vhTNVTeNMJGoGJFNn%2BUaPN0CJ0jr01HQy0hqyGViDA%40mail.gmail.com.

Reply via email to