RFC: arbitrary transformation for renderables
Роман Донченко
dpb at corrigendum.ru
Sun Oct 4 14:28:41 UTC 2015
Alright, I'll start working on the merge request, then.
I don't see how a cycle is possible here, BTW. (Unless you mess with a
Transform object after it's been created, which is definitely user error.)
Dustin J. Mitchell <dustin at v.igoro.us> писал в своём письме Sun, 04 Oct
2015 17:23:40 +0300:
> Ah, I see that the distinction is deeper than just allowing asynchronous
> returns -- Transform works on other renderables, whereas renderer creates
> new renderables (which take the build `b` as an argument).
>
> I like that this allows multiple renderables as input - nice design!
>
> There's a risk of circular dependencies, but I think we can consider that
> "user error" and not do anything to try to prevent it (cycle detection
> would be pretty hard here!).
>
> So yes, I think this would be a good addition to the property support.
>
> Dustin
>
> On Sun, Oct 4, 2015 at 10:12 AM, Роман Донченко <dpb at corrigendum.ru>
> wrote:
>
>> I don't see how that would work.
>>
>> IMO, renderer and Transform are very different things. The former
>> creates
>> a new renderable based on a user-defined function; the latter combines
>> existing renderables based on a user-defined transformation. They can't
>> (and shouldn't) be implemented by the same function.
>>
>> Dustin J. Mitchell <dustin at v.igoro.us> писал в своём письме Sun, 04 Oct
>> 2015 16:55:46 +0300:
>>
>>
>> Could you possibly extend renderer to handle that case?
>>>
>>> Dustin
>>>
>>> On Fri, Oct 2, 2015 at 4:17 PM, Роман Донченко <dpb at corrigendum.ru>
>>> wrote:
>>>
>>> Pierre Tardy <tardyp at gmail.com> писал в своём письме Fri, 02 Oct 2015
>>>> 00:25:36 +0300:
>>>>
>>>> Hi Roman,
>>>>
>>>>>
>>>>> There is already a renderer function which is similar simplification
>>>>> of
>>>>> the
>>>>> renderable pattern.
>>>>> You can do
>>>>>
>>>>> renderer(lambda _: datetime.date.today().isoformat()
>>>>> renderer(lambda b: os.path.relpath(p.getProperty('buildir'))
>>>>>
>>>>> The latter is a little bit more chars than your solution, but
>>>>> probably
>>>>> more
>>>>> easy to follow.
>>>>>
>>>>>
>>>> I know this, but it doesn't work when the arguments are arbitrary
>>>> renderables (since you have to account for the possibility that they
>>>> return
>>>> a Deferred). The brevity is nice to have, too.
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at buildbot.net
>>>> https://lists.buildbot.net/mailman/listinfo/devel
>>>>
More information about the devel
mailing list