New class hierarchy and better readiness checking

[liamhuber]

EDIT: This started as a mixin class so that Workflow and Macro could share code, but got #748 #750 #751 #753 #754 and #755 stacked (and #760), reviewed, and approved on top of it (well, almost approved, at least any explicit comments were addressed in each case).

Now this represents an overall refactoring of the workflow code, such that there is a base Node(ABC) class, a Function(Node), SingleValue(Function) and Slow(Function) branch, and a Composite(Node) and Workflow(Composite) (TBD: Macro(Composite)) branch.

It also includes two changes to functionality:

• The standard Function node that wraps python functions is now "fast" by default -- i.e. it runs on updates and updates on instantiation by default, and Slow was introduced (just Function with different default kwargs) for nodes which should require an explicit run call
• The above was facilitated by new "readiness" checking on DataNode, which initializes the data value to a new NotData class, such that ready is always false when the value is NotData

IMO these changes to the functionality really streamline the pedagogy, and I'm optimistic that the new structure to the code will make it much easier to incorporate Executor functionality and to extend things with a nice Macro class. There are still some rough edges, but the tests are reasonably thorough and passing (on my machine at least, as of writing I'm waiting for the CI here), and the examples are running nicely.

[github-actions]

👈 Launch a binder notebook on branch pyiron/pyiron_contrib/is_nodal_mixin

[github-actions]

Pull Request Test Coverage Report for Build 5535752745

• 324 of 363 (89.26%) changed or added relevant lines in 8 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.3%) to 12.857%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pyiron_contrib/workflow/node_library/package.py	1	2	50.0%
pyiron_contrib/workflow/workflow.py	27	28	96.43%
pyiron_contrib/workflow/composite.py	93	104	89.42%
pyiron_contrib/workflow/function.py	138	151	91.39%
pyiron_contrib/workflow/node.py	54	67	80.6%

Totals
Change from base Build 5535735027:	0.3%
Covered Lines:	1857
Relevant Lines:	14444

---

💛 - Coveralls

[samwaseda]

I'm fine with these changes, but since this one represents the concept of a node, I would like to see some documentation describing the overall ideas, especially for the most fundamental parts:

• inputs
• outputs
• update / run

And maybe also documentation that explains the specific idea of more technical attributes:

• connect / disconnect
• signals (?)

[liamhuber]

but since this one represents the concept of a node

I was thinking about this last night. Do we want to rename IsNodal to just Node? Then workflows are nodes! Then what is currently Node would become something like FunctionalNode. Then we'd have something like

Node, HasNodes, FunctionalNode(Node), MacroNode(Node, HasNodes), Workflow(Node, HasNodes (perhaps with some unification or deeper connection of MacroNode and Workflow, but I need to play with them more before seeing that.)

[liamhuber]

I'm fine with these changes, but since this one represents the concept of a node, I would like to see some documentation describing the overall ideas, especially for the most fundamental parts:

• inputs
• outputs
• update / run

And maybe also documentation that explains the specific idea of more technical attributes:

• connect / disconnect
• signals (?)

Excellent call. In the process of writing the docs I uncovered all sorts of todos I want to resolve before merging this, so it's back to draft. I'll explicitly ping you again when it's "ready", but of course feel free to critique at any intervening time.

At the moment I lean stronger towards my above comment of really having this just be Node, where we nail down expectations about what something that can sit in a graph is. My hope is that this will give us a single place to define how both single-function nodes and graph-running nodes interact with executors/servers, and may make it easier to close the gap between "macros" and "workflows".

• signals (?)

I'll probably make a separate PR adding more docs/rough spec to the channels and io modules directly, and here just reference that nodal objects ought to have collections for each of these channel types and keep the detail low.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[liamhuber]

Ok @samwaseda, I'm pretty happy with this. It's basically in line with #743 now.

You've already seen a bunch of it in the stacks, so I don't know how you want to handle review. Maybe it would be productive for us to have a live Zoom call some time next week and go through the notebook and main docstrings (and possibly the implementations) together? Might be a time-efficient way to find issues here, and also I think we're getting to the point that another brainstorming discussion will be fun and helpful. We could chat briefly after the meeting on Monday to nail down a time for that if you're keen.

[liamhuber]

@samwaseda, it's been a couple weeks so I'm going to go ahead and override the 3-week-old request for changes (adding docs) and merge this. We can patch it as needed if anything made it in that you don't like.