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 > <javascript:>> 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 >> <https://github.com/pypa/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 <javascript:>. >> To post to this group, send email to bean...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beancount/2d908091-190e-4320-abe3-83d587356cba%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beancount/2d908091-190e-4320-abe3-83d587356cba%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> 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 https://groups.google.com/d/msgid/beancount/70d31358-4032-45ca-9303-7a9bfbc933ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
