You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Yichi Zhang <zy...@google.com> on 2022/01/28 01:56:17 UTC
Swap gradle task.create() with task.register() if applicable?
Hi Beam Dev Community,
I realized that our beam gradle scripts use task.create() exclusively, for
example in BeamModulePlugin.groovy. This has led to some problems, for
example if people just want to run a spotlessApply for their java code
change they end up also configuring the python and go environment etc which
is probably unnecessary, and could even be blocked for quite a while if
their environment is missing the toolchain. Gradle recommended using task
configuration avoidance api when declaring tasks
https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#task_configuration_avoidance(TLDR:
swap task.create() with task.register()) thus that the configurations are
only evaluated when it is really needed for the task execution.
Any opinions on adopting the recommendations?
Yichi
Re: Swap gradle task.create() with task.register() if applicable?
Posted by Luke Cwik <lc...@google.com>.
This seems great if done consistently throughout the project.
An annoying pitfall is that the benefit of lazy configuration is only
realized if other tasks are also lazily configured. If you have
task X {
dependsOn Y
}
and you made Y lazy, well now X will force the configuration of Y now. So
you need to write (or something equivalent):
tasks.register("X") {
dependsOn Y
}
An eager task can easily remove the benefits of all the parents including
tasks defined in plugins. The gradle build scan does point out details
about lazy vs eager tasks so this can be tracked and improved upon over
time, similar to how the build deprecations warn of us future breaking
changes that we can proactively address.
On Fri, Jan 28, 2022 at 9:58 AM Yichi Zhang <zy...@google.com> wrote:
> > Is there any downside?
>
> I don't see any significant downside, there are some pitfalls
> <https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#sec:task_configuration_avoidance_pitfalls>
> to do a migration and the API is not compatible with gradle version < 5.1,
> I personally believe we should always use the configuration avoidance api.
>
> >Is there a Jira issue? Also, are you planning on implementing this?
>
> I created https://issues.apache.org/jira/browse/BEAM-13767, will draft a
> PR soon if there's no objection.
>
> On Fri, Jan 28, 2022 at 8:39 AM Kenneth Knowles <ke...@apache.org> wrote:
>
>> +1 very good initiative.
>>
>> Kenn
>>
>> On Fri, Jan 28, 2022 at 7:27 AM Kerry Donny-Clark <ke...@google.com>
>> wrote:
>>
>>> Sounds great. Is there a Jira issue? Also, are you planning on
>>> implementing this?
>>>
>>> On Thu, Jan 27, 2022 at 9:00 PM Brian Hulette <bh...@google.com>
>>> wrote:
>>>
>>>> I'm +1 for this, it's frustrating to run into issues with
>>>> other toolchains if you're only working in one SDK. Is there any downside?
>>>>
>>>> On Thu, Jan 27, 2022 at 5:56 PM Yichi Zhang <zy...@google.com> wrote:
>>>>
>>>>> Hi Beam Dev Community,
>>>>>
>>>>> I realized that our beam gradle scripts use task.create() exclusively,
>>>>> for example in BeamModulePlugin.groovy. This has led to some problems, for
>>>>> example if people just want to run a spotlessApply for their java code
>>>>> change they end up also configuring the python and go environment etc which
>>>>> is probably unnecessary, and could even be blocked for quite a while if
>>>>> their environment is missing the toolchain. Gradle recommended using task
>>>>> configuration avoidance api when declaring tasks
>>>>> https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#task_configuration_avoidance(TLDR:
>>>>> swap task.create() with task.register()) thus that the configurations are
>>>>> only evaluated when it is really needed for the task execution.
>>>>>
>>>>> Any opinions on adopting the recommendations?
>>>>>
>>>>> Yichi
>>>>>
>>>>
Re: Swap gradle task.create() with task.register() if applicable?
Posted by Yichi Zhang <zy...@google.com>.
> Is there any downside?
I don't see any significant downside, there are some pitfalls
<https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#sec:task_configuration_avoidance_pitfalls>
to do a migration and the API is not compatible with gradle version < 5.1,
I personally believe we should always use the configuration avoidance api.
>Is there a Jira issue? Also, are you planning on implementing this?
I created https://issues.apache.org/jira/browse/BEAM-13767, will draft a PR
soon if there's no objection.
On Fri, Jan 28, 2022 at 8:39 AM Kenneth Knowles <ke...@apache.org> wrote:
> +1 very good initiative.
>
> Kenn
>
> On Fri, Jan 28, 2022 at 7:27 AM Kerry Donny-Clark <ke...@google.com>
> wrote:
>
>> Sounds great. Is there a Jira issue? Also, are you planning on
>> implementing this?
>>
>> On Thu, Jan 27, 2022 at 9:00 PM Brian Hulette <bh...@google.com>
>> wrote:
>>
>>> I'm +1 for this, it's frustrating to run into issues with
>>> other toolchains if you're only working in one SDK. Is there any downside?
>>>
>>> On Thu, Jan 27, 2022 at 5:56 PM Yichi Zhang <zy...@google.com> wrote:
>>>
>>>> Hi Beam Dev Community,
>>>>
>>>> I realized that our beam gradle scripts use task.create() exclusively,
>>>> for example in BeamModulePlugin.groovy. This has led to some problems, for
>>>> example if people just want to run a spotlessApply for their java code
>>>> change they end up also configuring the python and go environment etc which
>>>> is probably unnecessary, and could even be blocked for quite a while if
>>>> their environment is missing the toolchain. Gradle recommended using task
>>>> configuration avoidance api when declaring tasks
>>>> https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#task_configuration_avoidance(TLDR:
>>>> swap task.create() with task.register()) thus that the configurations are
>>>> only evaluated when it is really needed for the task execution.
>>>>
>>>> Any opinions on adopting the recommendations?
>>>>
>>>> Yichi
>>>>
>>>
Re: Swap gradle task.create() with task.register() if applicable?
Posted by Kenneth Knowles <ke...@apache.org>.
+1 very good initiative.
Kenn
On Fri, Jan 28, 2022 at 7:27 AM Kerry Donny-Clark <ke...@google.com>
wrote:
> Sounds great. Is there a Jira issue? Also, are you planning on
> implementing this?
>
> On Thu, Jan 27, 2022 at 9:00 PM Brian Hulette <bh...@google.com> wrote:
>
>> I'm +1 for this, it's frustrating to run into issues with
>> other toolchains if you're only working in one SDK. Is there any downside?
>>
>> On Thu, Jan 27, 2022 at 5:56 PM Yichi Zhang <zy...@google.com> wrote:
>>
>>> Hi Beam Dev Community,
>>>
>>> I realized that our beam gradle scripts use task.create() exclusively,
>>> for example in BeamModulePlugin.groovy. This has led to some problems, for
>>> example if people just want to run a spotlessApply for their java code
>>> change they end up also configuring the python and go environment etc which
>>> is probably unnecessary, and could even be blocked for quite a while if
>>> their environment is missing the toolchain. Gradle recommended using task
>>> configuration avoidance api when declaring tasks
>>> https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#task_configuration_avoidance(TLDR:
>>> swap task.create() with task.register()) thus that the configurations are
>>> only evaluated when it is really needed for the task execution.
>>>
>>> Any opinions on adopting the recommendations?
>>>
>>> Yichi
>>>
>>
Re: Swap gradle task.create() with task.register() if applicable?
Posted by Kerry Donny-Clark <ke...@google.com>.
Sounds great. Is there a Jira issue? Also, are you planning on
implementing this?
On Thu, Jan 27, 2022 at 9:00 PM Brian Hulette <bh...@google.com> wrote:
> I'm +1 for this, it's frustrating to run into issues with other toolchains
> if you're only working in one SDK. Is there any downside?
>
> On Thu, Jan 27, 2022 at 5:56 PM Yichi Zhang <zy...@google.com> wrote:
>
>> Hi Beam Dev Community,
>>
>> I realized that our beam gradle scripts use task.create() exclusively,
>> for example in BeamModulePlugin.groovy. This has led to some problems, for
>> example if people just want to run a spotlessApply for their java code
>> change they end up also configuring the python and go environment etc which
>> is probably unnecessary, and could even be blocked for quite a while if
>> their environment is missing the toolchain. Gradle recommended using task
>> configuration avoidance api when declaring tasks
>> https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#task_configuration_avoidance(TLDR:
>> swap task.create() with task.register()) thus that the configurations are
>> only evaluated when it is really needed for the task execution.
>>
>> Any opinions on adopting the recommendations?
>>
>> Yichi
>>
>
Re: Swap gradle task.create() with task.register() if applicable?
Posted by Brian Hulette <bh...@google.com>.
I'm +1 for this, it's frustrating to run into issues with other toolchains
if you're only working in one SDK. Is there any downside?
On Thu, Jan 27, 2022 at 5:56 PM Yichi Zhang <zy...@google.com> wrote:
> Hi Beam Dev Community,
>
> I realized that our beam gradle scripts use task.create() exclusively, for
> example in BeamModulePlugin.groovy. This has led to some problems, for
> example if people just want to run a spotlessApply for their java code
> change they end up also configuring the python and go environment etc which
> is probably unnecessary, and could even be blocked for quite a while if
> their environment is missing the toolchain. Gradle recommended using task
> configuration avoidance api when declaring tasks
> https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#task_configuration_avoidance(TLDR:
> swap task.create() with task.register()) thus that the configurations are
> only evaluated when it is really needed for the task execution.
>
> Any opinions on adopting the recommendations?
>
> Yichi
>