Fix a bug with accessing hooks in EKS trigger

[hussein-awala]

The hook is defined as a standard method; converting it to a cached property is a breaking change. The best solution is to call this method to get the hook,

[vincbeck]

Another option could be to create the hook as a cached property and use this property in the code. To keep it backward compatible, you can just return the property in the method

[hussein-awala]

Another option could be to create the hook as a cached property and use this property in the code. To keep it backward compatible, you can just return the property in the method

The compatibility issue is not for us, but for the users who extend the trigger and create a subclass of it. Triggers are part of the Airflow public interface.

[vincbeck]

Another option could be to create the hook as a cached property and use this property in the code. To keep it backward compatible, you can just return the property in the method

The compatibility issue is not for us, but for the users who extend the trigger and create a subclass of it. Triggers are part of the Airflow public interface.

I understand but why that would not be backward compatible for these users?

[hussein-awala]

Currently, hook is a standard method, so if someone extends the trigger, he should use:

self.hook()

If we convert it to a cached_property, self.hook will return the hook, and the () will be applied on its value. A simple example:

>>> from functools import cached_property
>>> class X:
...     @cached_property
...     def x(self):
...             return 1
... 
>>> X().x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable

[vincbeck]

Oh yeah, I did not realize the 2 methods would have the same name. You can name the cached property method eks_hook but I guess it goes against the convention