(Eventual) native support for Windows?

[Jeff Brantley]

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

[Martin Blais]

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.

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

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

Agreed. Personally, I'm not ready to be that someone just yet.

 

I can promise not to make changes that would break it irremediably. 

This is really all I'm fishing for right now. Open to patches and intending not to irremediably break it. Patches can happen in due time from those--if anyone--who care enough, and the door is open to making that happen. Personally, this is enough to help me feel good about jumping in right now with the Ubuntu on Windows solution.

Thanks for taking time out of your weekend to respond.

-Jeff 

[Zhuoyun Wei]

2018-02-17 07:22:11 Jeff Brantley <jsb...@gmail.com>:

> 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

[Jeff Brantley]

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.

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

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

[Martin Blais]

On Tue, Feb 20, 2018 at 2:00 AM, Jeff Brantley <jsb...@gmail.com> 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+unsubscribe@googlegroups.com.
To post to this group, send email to bean...@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.

[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 <jsb...@gmail.com> 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 receiving emails from it, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

[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

[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