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


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 
>> 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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to