Re: [PROPOSAL] Standardize Gradle structure in Python SDK

Adding my comments below. On Mon, Jul 15, 2019 at 2:52 PM Kenneth Knowles wrote: > Gradle comments inline > > On Mon, Jul 15, 2019 at 2:30 AM Frederik Bode > wrote: > >> Hi Mark & others, >> >> +1 on using this structure. I don't see any other alternative to gradle >> as some of the Python

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

Gradle comments inline On Mon, Jul 15, 2019 at 2:30 AM Frederik Bode wrote: > Hi Mark & others, > > +1 on using this structure. I don't see any other alternative to gradle as > some of the Python tasks have Java tasks as > a dependency. You can't debug that using just `python nosetests... or >

[PROPOSAL] Standardize Gradle structure in Python SDK

Hi Mark & others, +1 on using this structure. I don't see any other alternative to gradle as some of the Python tasks have Java tasks as a dependency. You can't debug that using just `python nosetests... or tox`. Parallelizing such tasks requires different projects (and I don't think gradle

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

On Mon, Jun 3, 2019 at 5:13 PM Valentyn Tymofieiev wrote: > Hey Mark & others, > > We've been following the structure proposed in this thread to extend test > coverage for Beam Python SDK on Python 3.5, 3.6, 3.7 interpreters, see [1]. > > This structure allowed us to add 3.x suites without

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

Hey Mark & others, We've been following the structure proposed in this thread to extend test coverage for Beam Python SDK on Python 3.5, 3.6, 3.7 interpreters, see [1]. This structure allowed us to add 3.x suites without slowing down the pre/postcommit execution time. We can actually see a drop

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

I don't use gradle commands for Python development either, because they are slow (no incremental testing). On Fri, Mar 29, 2019 at 9:16 AM Michael Luckey wrote: > > > On Fri, Mar 29, 2019 at 2:31 PM Robert Bradshaw > wrote: > >> On Fri, Mar 29, 2019 at 12:54 PM Michael Luckey >> wrote: >> >

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

On Fri, Mar 29, 2019 at 2:31 PM Robert Bradshaw wrote: > On Fri, Mar 29, 2019 at 12:54 PM Michael Luckey > wrote: > > > > Really like the idea of improving here. > > > > Unfortunately, I haven't worked with python on that scale yet, so bear > with my naive understandings in this regard. If I

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

On Fri, Mar 29, 2019 at 12:54 PM Michael Luckey wrote: > > Really like the idea of improving here. > > Unfortunately, I haven't worked with python on that scale yet, so bear with > my naive understandings in this regard. If I understand correctly, the > suggestion will result in a couple of

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

Really like the idea of improving here. Unfortunately, I haven't worked with python on that scale yet, so bear with my naive understandings in this regard. If I understand correctly, the suggestion will result in a couple of projects consisting only of a build,gradle file to kind of workaround on

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

Thank you Ahmet. Answer your questions below: > - Could you comment on what kind of parallelization we will gain by this? > In terms of real numbers, how would this affect build and test times? The proposal is based on Gradle parallel execution

Re: [PROPOSAL] Standardize Gradle structure in Python SDK

This sounds good to me. Thank you for doing this. Few questions: - Could you comment on what kind of parallelization we will gain by this? In terms of real numbers, how would this affect build and test times? - I am guessing this will reduce complexity. Is it possible to quantify the improvement

[PROPOSAL] Standardize Gradle structure in Python SDK

Hi Python SDK Developers, You may notice that Gradle files changed a lot recently as parallelization applied to Python tests and more python versions were enabled in testing. There are tricks over the build scripts and tests are grown