Julian Schweizer

I concur with @PaulSchweizer - this would require fundamental changes to flowpipe. Most notably, as it stands, flowpipe has individual batches of work as inputs as a hard assumption. Each...

I like this idea a lot. A simple and probably very powerful way to move forward is to restrict the focus on the simple case that you present in your...

It should not be too hard to make the hashing function used there configurable. There is no specific reason I picked the `sha256` except for it being quite common and...

Oh, yes it is. This piece of logic makes sure that a plug/node stays clean if you set the same input again. Thay way, when you re-run the graph and...

It would be easy to make that hash function a constant in the `flowpipe.utilities` package and make use of python's lazy evaluation for convenient overriding. I'm talking about ``` ##...

I am looking forward to it, too. This will make communicating how our processing flow looks like much easier -- no more fiddling the graph together with inkscape :+1:

@Anton-4 I agree that it would make sense to distinguish formats for storing and restoring the graph, such as the pickle and json formats we have so far, and formats...

TBH, I would prefer a simple and clean export function to commonly used formats. Adding support for registering and calling visualizers seems a little much - I expect at most...

If interrupting the entire Graph is what you want, I would suggest you simply catch the exception outside the Graph execution. I want the Graph to finish executing, so I...

Interesting suggestion! I think it somewhat relates to https://github.com/PaulSchweizer/flowpipe/issues/139 - both issues could be solved easily by transitioning from a batch-processing approach towards a streaming architecture. Still, the option of...