Re: (Eventual) native support for Windows?

[Jeff Brantley]

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 

Re: (Eventual) native support for Windows?

[Jeff Brantley]

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 

Re: (Eventual) native support for Windows?

[Jeff Brantley]

On Wednesday, February 21, 2018 at 12:25:51 AM UTC-6, Martin Blais wrote:
>
> On Tue, Feb 20, 2018 at 2:00 AM, Jeff Brantley  > wrote:
>
>> The installation is self-contained and bundles 
>>> Cygwin, Python 3, and all the Python dependencies. It took ~100 MiB disk 
>>> space but it saves you from "polluting" your Windows with tons of 
>>> development tools. 
>>>
>>
>> Zhuoyun: while I could see the appeal of a turnkey installer for some 
>> users, I'm personally looking for something lighter weight. I just want to 
>> install beancount into an existing Python without needing C dev tools, or 
>> Cygwin, or WSL. I can't speak to the complexity of the project you 
>> referenced, but it sounds like beancount is already more-or-less runnable 
>> natively, with some rough edges that can probably be smoothed over.
>>
>> Since starting this thread, I've tried to learn more about python 
>> packaging. The ecosystem appears to accommodate compiled extensions 
>> (setuptools' bdist_wheel), which can be posted to PyPI alongside the source 
>> distribution. For Windows build and test, Microsoft offers free-to-use VMs, 
>> or there's free-for-OSS-use continuous integration (CI) service AppVeyor. 
>> It looks like there was some brief experimentation here with AppVeyor 
>> already; I'm not sure what the outcome was. Although my thread is about 
>> Windows, python-dev is a similarly burdensome install on Ubuntu. I see that 
>> Travis CI, also fee for OSS use, can be used to build manylinux 
>>  (and Mac) wheels.
>>
>
> Someone shared the appveyor config at some point and I patched it in - 
> cooperation - but I never actually tested it myself.
>
>
> Martin, you expressed your disinterest in package distribution and your 
>> preference to see it handled at the distro level, but as a user, I see 
>> value in handling it at the python packaging level. 
>>
>
> It's not disinterest, it's just way too much work (I'll spare you the 
> decades of pain trying to keep up with the RedHat packaging spec for my 
> other projects, or the various battles with distutils and setuptools, which 
> are the two packaging-like things I support, packaging looks easy, but in 
> practice it's an endless rabbit hole). I figure if you really care about 
> this particular package, you will do it and then please share for others to 
> enjoy.
>
> I believe you. I imagine Linux distro packaging to be more burdensome than 
python packaging, but of course the python packaging ecosystem has had a 
bumpy past, too. Don't know the headaches before trying, like you say.

>
> And that wouldn't need to be any concern of yours, except that your 
>> existing PyPI project would be the natural channel to publish binary 
>> wheels. That is, someone else could stand up a cloud-based CI build/test 
>> pipeline, but they wouldn't be able to publish the artifacts without your 
>> cooperation. What to do? At one extreme, someone could stand up the CI, get 
>> it healthy, and then turn it over to you. At the other extreme, if a 
>> devoted CI owner emerged, you could just turn over the PyPI project to them 
>> and only manage the source repo, truly separating yourself from any 
>> packaging responsibility. In between, you could manually upload CI-produced 
>> artifacts to PyPI, or you could deputize a trusted person to do so per some 
>> agreed-upon policy. At both extremes, having a single owner opens the 
>> possibility of automatically publishing tested prerelease builds to PyPI, 
>> assuming the test discipline is good enough.
>>
>
> Maybe I should start by versioning in the first place   8-P
>
> Yeah in any case that will probably be warranted. =)
 

> Let me see someone generate and distribute a binary package for it 
> somewhere else regularly for 6 months, and then I could figure out some 
> arrangement. Let's see someone OWN this because it matters to enough 
> people. The difficult part is not the setup - setup.py will build it 
> alright if you have an install and a compiler - it's all the unpredictables 
> that occur over time. It's like gardening... The Windows packaging needs 
> someone to own it.
>
> That sounds sensible. I don't (yet) have any idea what that somewhere 
should be, except that it should *not* be another PyPI project with a 
variation on the name "beancount".  Suggestions welcome. For my part, I 
will just take one small step at a time and see where it leads. Like this 
evening, I started looking into the launcher-script issue I filed over the 
weekend...

>
> Of course, this is all hypothetical until such a person emerges. I do have 
>> the motivation, but I'm unsure how much time I could carve out on a regular 
>> basis. For now, I'm again just probing for your thoughts on the potential 
>> endpoint.
>>
>> Thanks again,
>> Jeff
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Beancount" group.
>> To unsubscribe from this group and stop 

Re: (Eventual) native support for Windows?

[Martin Blais]

On Tue, Feb 20, 2018 at 2:00 AM, Jeff Brantley  wrote:

> The installation is self-contained and bundles
>> Cygwin, Python 3, and all the Python dependencies. It took ~100 MiB disk
>> space but it saves you from "polluting" your Windows with tons of
>> development tools.
>>
>
> Zhuoyun: while I could see the appeal of a turnkey installer for some
> users, I'm personally looking for something lighter weight. I just want to
> install beancount into an existing Python without needing C dev tools, or
> Cygwin, or WSL. I can't speak to the complexity of the project you
> referenced, but it sounds like beancount is already more-or-less runnable
> natively, with some rough edges that can probably be smoothed over.
>
> Since starting this thread, I've tried to learn more about python
> packaging. The ecosystem appears to accommodate compiled extensions
> (setuptools' bdist_wheel), which can be posted to PyPI alongside the source
> distribution. For Windows build and test, Microsoft offers free-to-use VMs,
> or there's free-for-OSS-use continuous integration (CI) service AppVeyor.
> It looks like there was some brief experimentation here with AppVeyor
> already; I'm not sure what the outcome was. Although my thread is about
> Windows, python-dev is a similarly burdensome install on Ubuntu. I see that
> Travis CI, also fee for OSS use, can be used to build manylinux
>  (and Mac) wheels.
>

Someone shared the appveyor config at some point and I patched it in -
cooperation - but I never actually tested it myself.


Martin, you expressed your disinterest in package distribution and your
> preference to see it handled at the distro level, but as a user, I see
> value in handling it at the python packaging level.
>

It's not disinterest, it's just way too much work (I'll spare you the
decades of pain trying to keep up with the RedHat packaging spec for my
other projects, or the various battles with distutils and setuptools, which
are the two packaging-like things I support, packaging looks easy, but in
practice it's an endless rabbit hole). I figure if you really care about
this particular package, you will do it and then please share for others to
enjoy.


And that wouldn't need to be any concern of yours, except that your
> existing PyPI project would be the natural channel to publish binary
> wheels. That is, someone else could stand up a cloud-based CI build/test
> pipeline, but they wouldn't be able to publish the artifacts without your
> cooperation. What to do? At one extreme, someone could stand up the CI, get
> it healthy, and then turn it over to you. At the other extreme, if a
> devoted CI owner emerged, you could just turn over the PyPI project to them
> and only manage the source repo, truly separating yourself from any
> packaging responsibility. In between, you could manually upload CI-produced
> artifacts to PyPI, or you could deputize a trusted person to do so per some
> agreed-upon policy. At both extremes, having a single owner opens the
> possibility of automatically publishing tested prerelease builds to PyPI,
> assuming the test discipline is good enough.
>

Maybe I should start by versioning in the first place   8-P

Let me see someone generate and distribute a binary package for it
somewhere else regularly for 6 months, and then I could figure out some
arrangement. Let's see someone OWN this because it matters to enough
people. The difficult part is not the setup - setup.py will build it
alright if you have an install and a compiler - it's all the unpredictables
that occur over time. It's like gardening... The Windows packaging needs
someone to own it.


Of course, this is all hypothetical until such a person emerges. I do have
> the motivation, but I'm unsure how much time I could carve out on a regular
> basis. For now, I'm again just probing for your thoughts on the potential
> endpoint.
>
> Thanks again,
> 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/2d908091-190e-4320-abe3-83d587356cba%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: (Eventual) native support for Windows?

[Zhuoyun Wei]

2018-02-17 07:22:11 Jeff Brantley :
> 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 would like to share a successful example as a potential approach of
"native" Windows release of Beancount: 
https://github.com/borgbackup/borg/issues/440

BorgBackup is an excellent backup tool (try it out!) written in Python
and Cython. So compiling it in Windows is a headache, just like
Beancount. A contributor finally created an all-in-one Windows binary
installer for BorgBackup. The installation is self-contained and bundles
Cygwin, Python 3, and all the Python dependencies. It took ~100 MiB disk
space but it saves you from "polluting" your Windows with tons of
development tools.

I have been using the Windows BorgBackup release on my gaming PC for a
few months and it works well. You may consider creating a similar
Beancount Windows release as well.


-- 
Zhuoyun Wei

-- 
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/20180219094606.GA10631%40herus.wzyboy.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: (Eventual) native support for Windows?

[Jeff Brantley]

On Saturday, February 17, 2018 at 2:56:47 PM UTC-6, Martin Blais wrote:
>
> On Sat, Feb 17, 2018 at 10:22 AM, 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.
>>
>
> I'm open to patches.
> The only thing is I can't really test things, I don't have a Windows box.
>

Cool. This is about what I was hoping/expecting to hear.
 

> 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.
>
> Once I got the "minimal" amount of Visual Studio crud installed, 
installing beancount was smooth. I opened the ticket about launch scripts 
before running into some of the other papercuts below. 

>
> 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.
>
> An understandable position.
 

>  
>
>> 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.
>
> Right, I don't doubt it will be do-able to re-generate these if you walk 
in front of a bus tomorrow; I'm thinking more about the level of difficulty 
or convenience of consuming changes month-to-month, year-to-year.

>  
>
>> 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.
>
> I had assumed this was a more fundamental blocker; good to know it's 
optional. Would it just be a degraded experience w.r.t. recalling/tweaking 
prior queries? 

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

Re: (Eventual) native support for Windows?

[Martin Blais]

On Sat, Feb 17, 2018 at 10:22 AM, 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.
>

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,