>
> 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 
<https://github.com/pypa/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

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

Reply via email to