Sympy objects in nested_tasks

[elleryames]

Currently arbitrary python objects cannot be referenced within nested_tasks, since the logic of the nested task gets evaluated and embedded in the workflow. However, it would be desirable to loosen this restriction somewhat. One idea is to make use of sympy, such that the object to be referenced in the nested task can be expressed in sympy, then dewret can represent represent it in the workflow.

Yes - good point. I'm tempted to write that once I have the sympy functionality working, so we can say "if you can write it with sympy it's gtg" or something like that. (although agree if that's not right now, then it should be noted regardless)

_Originally posted by @philtweir in https://github.com/flaxandteal/dewret/pull/15#discussion_r1573040329_

[philtweir]

Action points:

• [ ] Implement a way of capturing the body of nested_tasks
• [ ] Document the limitations of this

[philtweir]

Working through this, it might be sufficient - if not very elegant - to leave this up to the backend. I have PoC'd using dask to extract the subgraph corresponding to arithmetic/dask.array operations, where the other steps are dependencies. This would give us as much flexibility as dask.delayed has but with (at least) two major caveats:

• it is not clear whether/how this would translate to other frameworks (they would have to allow, at least, arithmetic operations on their lazy fundamentals, i.e. the corresponding types to what dask.delayed creates)
• using sympy gives us readable representations of the logic; using dask gives us subgraph dictionaries, without a reliable way back