pyiron / pyiron_workflow

Graph-and-node based workflows
BSD 3-Clause "New" or "Revised" License
10 stars 1 forks source link

[minor] Explicit macro io #276

Closed liamhuber closed 2 months ago

liamhuber commented 2 months ago

The key change here is that AbstractMacro no longer supports the inputs_map or outputs_map parameter or attribute. Further, macros no longer auto-populate IO based on the unconnected IO of their children. (Both these features are still available on Workflow, which retains by-reference IO.) I.e. you must define all macro IO at the class level via output_labels (or the class property _provided_output_labels if you're directly subclassing and not using a creator) and the signature and return values of the graph_creator. This brings macro and function nodes substantially closer together.

As a side effect of doing this, I had to re-write the for- and while-loop meta nodes, which relied heavily on the maps. While these are substantially different under the hood now, there is extremely minimal user facing changes: the while_loop now requires the inputs_map and outputs_map parameters instead of having these be optional (although the syntax and impact of the dictionaries passed is unchanged), and neither function can accept un-importable classes for looping on (this is a pretty edge case, basically no defining a class inside some function or class scope and then trying to loop over it).

Changes to the while-loop and macro exploitation of UI nodes had the knock-on effect that I needed new connections to prepend to the connections list instead of append. Recall that when fetching data we always took data from the first source in our connection list that offered it; now we are just giving higher priority to newer connections instead of older ones (this is documented in the Node docstring).

Non-goal: Actually making the loop nodes I want, described in #268 -- here I tried to keep the minimal changes that would let all the tests pass.

EDIT: Also for-loops are now creating channels for all their body node's input, and not taking any of the defaults or hints from the body node (this is really tricky to convert to text, and I want to change these loops anyhow so I didn't spend all day on that) -- so that means all the channels need input. A pain, but a manageable one.

github-actions[bot] commented 2 months ago

Binder :point_left: Launch a binder notebook on branch _pyiron/pyiron_workflow/explicit_macroio

codacy-production[bot] commented 2 months ago

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
:white_check_mark: -0.59% (target: -1.00%) :white_check_mark: 76.02%
Coverage variation details | | Coverable lines | Covered lines | Coverage | | ------------- | ------------- | ------------- | ------------- | | Common ancestor commit (14064ea6f0729b9966cd5a7a45977d5ef788929b) | 3420 | 2999 | 87.69% | | | Head commit (92f0c6cc1e60ab052b3b2ad046de08b628609c55) | 3442 (+22) | 2998 (-1) | 87.10% (**-0.59%**) | **Coverage variation** is the difference between the coverage for the head and common ancestor commits of the pull request branch: ` - `
Diff coverage details | | Coverable lines | Covered lines | Diff coverage | | ------------- | ------------- | ------------- | ------------- | | Pull request (#276) | 221 | 168 | **76.02%** | **Diff coverage** is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: `/ * 100%`

See your quality gate settings    Change summary preferences

You may notice some variations in coverage metrics with the latest Coverage engine update. For more details, visit the documentation

review-notebook-app[bot] commented 2 months ago

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB