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 
>> 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/8bb95007-609c-4ab4-a695-9e123ec82b67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to