On Sat, Feb 17, 2018 at 10:22 AM, Jeff Brantley <jsb...@gmail.com> 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. > I'm open to patches. The only thing is I can't really test things, I don't have a Windows box. The source code depends only on having a C compiler and everything else is pure-Python, so it really should work, I don't see any problem. (That's on purpose, BTW, minimizing dependencies in the interest of portability.) > 3. Do we have a feel for what gaps exist that would have to be addressed? > I think the pain points I've heard about are mostly around installation and invocation scripts. I thought we had fixed all the installation issues? I'm not sure if there's any other problem. There's an open ticket right now about .bat files for launch scripts. 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). > I agree. However, I decided to get out of the package distribution business for my various projects decades ago. There's always a good soul somewhere who cares more than I do who will do the packaging. In my experience, the best model to deal with packaging IMO is for people from each platform / distribution to develop their own packaging scripts (with all their quirks), and for the software developer to help out by cooperating and applying the occasional patch to make it easier on them. > 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? > No plan to ever change that, don't worry. The files are generated there for your convenience, and I'm glad it helps Windows users. Besides, they should be easy to generate on a cloud machine (or a Win box with Cygwin) should you ever find yourself without them. And the software is all open... so. > c) bean-query requires readline, which is unavailable on Windows. There is > a pure python module pyreadline, but it appears to be abandoned. > Ah, yes indeed. I can make that optional if it helps. That should be doable. d) Probably minor: bean-web seems to work but is not responsive to > Control+C. > That's either a Windows shell problem or something due to signals being overridden. The latter is fixable. (TBH I shouldn't make bean-web run from wsgiref.simple_server, but then I'd have to depend on yet another thing.) > 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. > This one is an issue I can't fix without a box. I don't remember how IE (Edge?) treats static files. (You don't really need bean-bake, totally optional.) > 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. > If supporting it involves the applying the occasional patch I'm totally fine with that (of course, assuming the patch has tests, where relevant). However I think it would take someone who really cares about the Windows platform to do the work, if you'd like it to be guaranteed to work really well all the time and a nice binary package you can download. I can promise not to make changes that would break it irremediably. -- 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%2BhPDstPs%3DKFiHLXKDNxOyP26rV3%3DavLB9FQ9MDNZ_eC%2BoQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
