This seemed on-topic enough (I hope). While testing a fix 
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 install (with distutils)
   - python install (with setuptools)
   - pip install

...also, one extra case of bdist_wheel built with wheel/setuptools and 
installed with pip.


   - 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 install (with 
   setuptools) from source or from a distutils-created-sdist. On Windows and 

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


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 question of who (I'd *like* to find the time) would 
> work on it, and on what timeframe.
> Thanks
> Jeff

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 post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to