I'd like to remove Workflow.register, NodePackage, and everything related. Instead, one would simply import nodes from a python package like any other python object. (Note: this has no impact on Workflow.create -- stuff like Workflow.create.standard.UserInput would still be perfectly accessible, it just means you won't be creating anything defined outside the pyiron_workflow module this way.)
This is not backwards-compatible in that it breaks syntax for creating nodes in some of our current use cases, but doesn't make any real conceptual change.
from pyiron_workflow import Workflow
from some_parent_package import my_nodes_module as shortcut
wf = Workflow("with_registration")
wf.foo = shortcut.Foo(42)
Pros:
Simpler, more like python
Less code to maintain
Less overhead for node developers, i.e. no need to remember nodes=[Node1, Node2, ...] at the end of your module with nodes
Cons:
We get rid of the extra (currently unused) infrastructure for tracking node versioning
Currently this doesn't conflict with anything, so in the spirit of KISS and YAGNI (well, Y-didn't-wind-up-NI) I think it's an easy win. My vision is that any FAIR versioning stuff is handled at the level of how the python module is versioned. E.g. we can look at version numbers, or even things like the directory of __module__ to see if it's a git repo and check the hash. In any case, treat it as a generic problem for python rather than specific problem for children of Node.
@srmnitc you are my go-to for FAIR wisdom -- does this sound OK to you?
I'd like to remove
Workflow.register,NodePackage, and everything related. Instead, one would simply import nodes from a python package like any other python object. (Note: this has no impact onWorkflow.create-- stuff likeWorkflow.create.standard.UserInputwould still be perfectly accessible, it just means you won't be creating anything defined outside thepyiron_workflowmodule this way.)This is not backwards-compatible in that it breaks syntax for creating nodes in some of our current use cases, but doesn't make any real conceptual change.
Concretely:
would become
Pros:
nodes=[Node1, Node2, ...]at the end of your module with nodesCons:
Currently this doesn't conflict with anything, so in the spirit of KISS and YAGNI (well, Y-didn't-wind-up-NI) I think it's an easy win. My vision is that any FAIR versioning stuff is handled at the level of how the python module is versioned. E.g. we can look at version numbers, or even things like the directory of
__module__to see if it's a git repo and check the hash. In any case, treat it as a generic problem for python rather than specific problem for children ofNode.@srmnitc you are my go-to for FAIR wisdom -- does this sound OK to you?