Link-attached balances
I had an idea tonight while attempting to reconcile some missing amounts over a credit card account where my last balance was last year September. The problem is this: Beancount does not include time nor care about ordering in the file. This is a really important property and I don't want to ever change that. However, this means that it's impossible to create balance checks in between transactions that occur on the same day. However, this type of thing happens all the time with credit cards. There's no solution at the moment, other than fudging the amounts, which is really super annoying. I thought about this: How about I'd add an OPTIONAL link to balance checks, or create a new type of balance directive. If the link is present, the semantics would be: check the balance that occurs just before the transaction which occurs on that same day, and which is the only one with that link. (If there are more than one transaction on that day with the link an error should be issued, IOW, it should be unambiguous.) Now, this seems straightforward to implement - and I was just about to pounce! - but it's not: there's a whole lot of sorting going on, and it might affect display as well. I'm not sure yet how to it. Ideas welcome. -- 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 post to this group, send email to beancount@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOfctKkL%3DoF4PgD3f_zDkMTyBWHFc5GRt5GAwqm%2BrkpRA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: (Eventual) native support for Windows?
Unfortunately, I was a bit distracted and rushed typing this post.
Finishing my train of thought now...
Additional comments on methodology. I did every build and every install
check in a fresh virtualenv, using --without-pip as needed to get distutils
only. My measure for whether it worked is no install errors and the ability
to run `bean-check` unqualified.
Additional result: Using distutils to install seems to work, except even
with the proposed fix I mentioned, the bean-X scripts cannot invoked
unqualified on windows. Pip install works fine (against all of: sdist,
bdist_wheel, and source)
*So, in conclusion, the current state of things (with aforementioned fix
for Windows):*
- A vanilla distutils workflow seems still workable (if manual) on
Ubuntu, and a little broken on Windows
- pip is pretty foolproof, as you'd expect
- Baking binary wheels in addition to sdist looks viable, but the sdist
must be built in a separate vanilla-distutils environment
*whew*
-Jeff
On Friday, February 23, 2018 at 8:16:30 AM UTC-6, Jeff Brantley wrote:
>
> This seemed on-topic enough (I hope). While testing a fix to
> https://bitbucket.org/blais/beancount/issues/217/cannot-invoke-top-level-scripts,
>
> I was inspired to do some amount of installation matrix testing just to get
> a feel for what does or does not work currently. I am not implying that all
> of these should work or should be supported, and in fact, it seems sane
> only no target an explicit subset.
>
> Installation sources:
>
>- An sdist created with distutils
>- An sdist created with setuptools
>- The repo source itself ("installing from source")
>
> Installation methods:
>
>- python setup.py install (with distutils)
>- python setup.py install (with setuptools)
>- pip install
>
> ...also, one extra case of bdist_wheel built with wheel/setuptools and
> installed with pip.
>
> Observations:
>
>- pip-installing source or distutils-created sdist works fine
>- pip-installing a bdist_wheel works fine
>- setuptools-created sdists are broken due to use of 'data_files' to
>distribute beancount.el. I.e., as is, releases must be baked sans
>setuptools. (`python -m venv --without-pip ENV` can be used to hide from
>setuptools, if installed)
>- On my box, compilation failed trying to setup.py install (with
>setuptools) from source or from a distutils-created-sdist. On Windows and
>Ubuntu/WSL.
>
> I'm happy the first two cases worked. I don't necessarily care about the
> third case, except that it means a mixed sdist/bdist_wheel release would
> require care to avoid producing the sdist from a fully-loaded
> wheels/setuptools environment.
>
> Anyway, did the grunt work of hand-testing those cases and figured I might
> as well share...
>
> -Jeff
>
> On Saturday, February 17, 2018 at 9:22:11 AM UTC-6, Jeff Brantley wrote:
>>
>> Ok folks, I acknowledge that I may be walking to a minefield by even
>> asking this question, but I am not trying to troll; I am asking in earnest.
>> I've been using GnuCash for the past two years, but I'm interested in
>> migrating to beancount. The general philosophy permeating the documentation
>> (e.g., command-line accounting in context, comparison to ledger, design
>> document) resonates strongly with me as both a software engineer and a user.
>>
>> However, for me, the lack of native Windows support feels at odds with
>> the general aims of openness and access to one's data exemplified in plaint
>> text accounting. I'm not trying to levy a criticism of Martin, this project
>> he has poured so much work into, his intentions, etc. I'm simply speaking
>> as a potential user evaluating whether to jump on board. In general, I feel
>> uneasy about having to use a virtualized solution (i.e., virtual machine,
>> Cygwin, WSL/Ubuntu) for something I'd hope to accumulate for decades. (Less
>> generally, I might eventually want to work on, say, a Sublime Text plugin
>> that can invoke beancount features.) I would feel less uneasy migrating now
>> if I thought there were a realistic path to eventual (e.g., next handful of
>> years?) native support.
>>
>> So, what I want to ask is:
>> 1. Do others share this concern?
>> 2. What is Martin's perspective on this? I gather he does not use
>> Windows, and this is likely not a priority for his own efforts, but what is
>> his openness to accommodating native support for Windows? I'm sure it
>> depends on what is required to get there.
>> 3. Do we have a feel for what gaps exist that would have to be addressed?
>>
>> Regarding #3, some things that I have observed so far:
>> a) One has to install 3-4 GiB of compiler/build tools from Microsoft in
>> order to compile the C portions on the fly. This is workable, but ideally
>> this would be distributed as a binary wheel (or whatever, I'm no expert on
>> python packaging).
>> b) Compilation only works at all because Martin is currently willing to
Re: (Eventual) native support for Windows?
This seemed on-topic enough (I hope). While testing a fix
to
https://bitbucket.org/blais/beancount/issues/217/cannot-invoke-top-level-scripts,
I was inspired to do some amount of installation matrix testing just to get
a feel for what does or does not work currently. I am not implying that all
of these should work or should be supported, and in fact, it seems sane
only no target an explicit subset.
Installation sources:
- An sdist created with distutils
- An sdist created with setuptools
- The repo source itself ("installing from source")
Installation methods:
- python setup.py install (with distutils)
- python setup.py install (with setuptools)
- pip install
...also, one extra case of bdist_wheel built with wheel/setuptools and
installed with pip.
Observations:
- pip-installing source or distutils-created sdist works fine
- pip-installing a bdist_wheel works fine
- setuptools-created sdists are broken due to use of 'data_files' to
distribute beancount.el. I.e., as is, releases must be baked sans
setuptools. (`python -m venv --without-pip ENV` can be used to hide from
setuptools, if installed)
- On my box, compilation failed trying to setup.py install (with
setuptools) from source or from a distutils-created-sdist. On Windows and
Ubuntu/WSL.
I'm happy the first two cases worked. I don't necessarily care about the
third case, except that it means a mixed sdist/bdist_wheel release would
require care to avoid producing the sdist from a fully-loaded
wheels/setuptools environment.
Anyway, did the grunt work of hand-testing those cases and figured I might
as well share...
-Jeff
On Saturday, February 17, 2018 at 9:22:11 AM UTC-6, Jeff Brantley wrote:
>
> Ok folks, I acknowledge that I may be walking to a minefield by even
> asking this question, but I am not trying to troll; I am asking in earnest.
> I've been using GnuCash for the past two years, but I'm interested in
> migrating to beancount. The general philosophy permeating the documentation
> (e.g., command-line accounting in context, comparison to ledger, design
> document) resonates strongly with me as both a software engineer and a user.
>
> However, for me, the lack of native Windows support feels at odds with the
> general aims of openness and access to one's data exemplified in plaint
> text accounting. I'm not trying to levy a criticism of Martin, this project
> he has poured so much work into, his intentions, etc. I'm simply speaking
> as a potential user evaluating whether to jump on board. In general, I feel
> uneasy about having to use a virtualized solution (i.e., virtual machine,
> Cygwin, WSL/Ubuntu) for something I'd hope to accumulate for decades. (Less
> generally, I might eventually want to work on, say, a Sublime Text plugin
> that can invoke beancount features.) I would feel less uneasy migrating now
> if I thought there were a realistic path to eventual (e.g., next handful of
> years?) native support.
>
> So, what I want to ask is:
> 1. Do others share this concern?
> 2. What is Martin's perspective on this? I gather he does not use Windows,
> and this is likely not a priority for his own efforts, but what is his
> openness to accommodating native support for Windows? I'm sure it depends
> on what is required to get there.
> 3. Do we have a feel for what gaps exist that would have to be addressed?
>
> Regarding #3, some things that I have observed so far:
> a) One has to install 3-4 GiB of compiler/build tools from Microsoft in
> order to compile the C portions on the fly. This is workable, but ideally
> this would be distributed as a binary wheel (or whatever, I'm no expert on
> python packaging).
> b) Compilation only works at all because Martin is currently willing to
> generate and check in the .h/.c files "offline". Does Martin want to move
> away from this?
> c) bean-query requires readline, which is unavailable on Windows. There is
> a pure python module pyreadline, but it appears to be abandoned.
> d) Probably minor: bean-web seems to work but is not responsive to
> Control+C.
> e) bean-bake breaks, and it appears it's due to assuming / is a valid path
> separator. Assuming these paths are generated within pure python code, this
> would not be a fundamental roadblock, just something to file an issue on
> and/or propose a fix.
> f) bean-doctor deps notes python-magic is NOT INSTALLED. I'm not sure what
> this effects. It looks like there may be a binary version of this package
> for windows; I haven't explored this deeply yet.
>
> I'm sure there are other issues to be found, since I've only tried a few
> commands so far, but it's just a question of whether they are fundamental
> blockers. My goal is not to formulate a complete issue list or action plan
> in this thread. Rather, *I'd like to hear Martin's perspective on this,
> and feel out whether there is at least a path to native Windows support*,
> separately from the
