Since workflows have to be registered with the worker ANYWAY, I don't see why all the things that might need the client or additional configuration can't be handled at that point:
It seems to me that it would be much cleaner if Workflows could be defined declarative apart from any dynamic configuration that is needed to actually talk to a particular hatchet instance.
one idea for how to pull this off is to make everything that is calculated eagerly in the new of workflow meta, instead be calculated dynamically/lazily as part of the call to get_actions, here:
As it stands, the workflow and step decorators have to be defined using a Hatchet App instance:
workflow https://github.com/hatchet-dev/hatchet-python/blob/e358266f17da07a28373766c48ca68885cccc804/hatchet_sdk/hatchet.py#L59
step
https://github.com/hatchet-dev/hatchet-python/blob/e358266f17da07a28373766c48ca68885cccc804/hatchet_sdk/hatchet.py#L82
As far as I can tell, the only place where the client attribute that is set on the workflow meta is actually used is here where it is actually just used to access the configuration namespace. https://github.com/hatchet-dev/hatchet-python/blob/e358266f17da07a28373766c48ca68885cccc804/hatchet_sdk/workflow.py#L16
Since workflows have to be registered with the worker ANYWAY, I don't see why all the things that might need the client or additional configuration can't be handled at that point:
https://github.com/hatchet-dev/hatchet-python/blob/2b54d5454156555175ad8ab973e3761a984a092b/hatchet_sdk/worker.py#L500
It seems to me that it would be much cleaner if Workflows could be defined declarative apart from any dynamic configuration that is needed to actually talk to a particular hatchet instance.
one idea for how to pull this off is to make everything that is calculated eagerly in the new of workflow meta, instead be calculated dynamically/lazily as part of the call to get_actions, here:
https://github.com/hatchet-dev/hatchet-python/blob/2b54d5454156555175ad8ab973e3761a984a092b/hatchet_sdk/worker.py#L514