I'd be in favor of this, assuming it actually simplifies things. (Note that the wheels are for several variants of linux, presumably we could do cross-compiles. Also, manylinux is a "minimal" linux specifically built as to produce shared object libraries compatible with a wide variety of distributions--we can't just assume that a shared object library built on one modern linux will just work on another. (But maybe it's sufficient to do this within a docker environment?)
On Tue, Feb 25, 2020 at 2:23 PM Kenneth Knowles <k...@apache.org> wrote: > > +1 to exploring this. > > On bui...@apache.org there is lots of discussion and general approval for > trying it. It is enabled and used by some projects. Calcite uses it to build > their website, for example. > > Kenn > > > On Tue, Feb 25, 2020 at 2:08 PM Ahmet Altay <al...@google.com> wrote: >> >> Hi all, >> >> I recently had a chance to look at the documentation for github actions. I >> think we could use github actions instead of travis to for building python >> wheels during releases. This will have the following advantages: >> >> - We will eliminate one repo. (If you don't know, we have >> https://github.com/apache/beam-wheels for the sole purpose of building >> wheels file.) >> - Workflow will be stored in the same repo. This will prevent bit rot that >> is only discovered at release times. (happened a few times, although usually >> easy to fix.) >> - github actions supports ubuntu, mac, windows environments. We could try to >> build wheels for windows as well. (Travis also supports the same >> environments but we only use linux and mac environments. Maybe there are >> other blockers for building wheels for Windows.) >> - We could do more, like daily python builds. >> >> Downsides would be: >> - I do not know if github actions will require some special set of >> permissions that require an approval from infra. >> - Travis works fine most of the time. This might be unnecessary work. >> >> What do you think? Is this feasible, would this be useful? >> >> Ahmet
