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