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 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 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/088a19e7-0e68-4fc2-8f41-cb20b053305f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
