Reset workflow button

[Tara-Lakshmipathy]

A button in the global commands div for fully clearing and actually reinstantiating the workflow would be nice to have. Not sure how that would interact with a saved pickle with the current setup though. @liamhuber, would there be a way to reinstantiate a worklow that has been saved to disk and add children to the workflow with labels that were already in the older workflow before reinstantiation (a.k.a ignore the save file and proceed in the session, but save file still there on disk ready to be loaded)?

[liamhuber]

I'm unclear here. You want a second, independent workflow instance, that happens to have the same name, and then you want to copy all the children (and their connections) from the first instance over to the second instance?

This is technically possible, although I haven't made shortcuts to make it easy so you really need to manually loop over children and connections etc. But why on earth would you want to? You already have such a thing, it's your first workflow instance.

[Tara-Lakshmipathy]

Actually I don't want to copy over all the children. Let's say I started composing a workflow and introduced 5 or 6 nodes from the node library and saved the workflow. Then I realized I messed up somewhere with the nodes. Now I want to recompose the workflow again with just 3-4 nodes from the original workflow and 2-3 other nodes.

Currently, I can do this by just starting a new workflow wf = Worflow("my_workflow_1") or by deleting the save, but that's a bit tedious. So, I would like a feature that allows me to either ignore the save file, or create new workflow instances the way Jupyter automatically creates new notebooks like "Untitled1", "Untitled2" etc. Or just ignore the save and let me work with the same name of the workflow.

EDIT: by mess up with the nodes, I mean mess up with the backend part of the nodes. So, I changed something about the nodes in the backend and want to start over. I don't need to restart the kernel anyway because of the refresh feature in the node library.

TL;DR: The current setup of not reinstanting workflows all the time makes the refresh node library button not work as intended because nodes with the label have already been added to the workflow.

[pmrv]

You should be able to just use the Delete button now with #85

[Tara-Lakshmipathy]

@pmrv but I don't want to delete the workflow in case I want to come back to it... 😢 Of course I can create a copy elsewhere from the file system side, but ideally the user should be able to manage this from the GUI.

[pmrv]

I had to disable the refresh feature of the node library, btw. because this messes with the type hinting on complex outputs. There's a flag to re-enable it, see #96

[pmrv]

@pmrv but I don't want to delete the workflow in case I want to come back to it... 😢 Of course I can create a copy elsewhere from the file system side, but ideally the user should be able to manage this from the GUI.

Ah, I see. But this should be easy to add. Add a new button and a new GlobalCommand and on handling it remove all children from the workflow.

[Tara-Lakshmipathy]

I had to disable the refresh feature of the node library, btw. because this messes with the type hinting on complex outputs. There's a flag to re-enable it, see #96

Could you explain briefly how things were getting messed up, curious about it now.

[liamhuber]

You can always ignore an existing save but get the same name using autoload=None.

IMO the problem you're describing is best solved in a GUI context by deleting all the nodes you want to get rid of and continuing with the original instance.

[liamhuber]

There is also a replace_child method that may be more directly useful if you want to update a child class and place the refreshed instance into an existing wf

[pmrv]

I had to disable the refresh feature of the node library, btw. because this messes with the type hinting on complex outputs. There's a flag to re-enable it, see #96

Could you explain briefly how things were getting messed up, curious about it now.

If you have a class definition in a file a.py

class A: pass

then the following holds

import a
v = a.A()
assert isinstance(v, a.A)
from importlib import reload
reload(a)
assert not isinstance(v, a.A)

In effect classes with the same name from the same module are not equivalent when reloading, because their code may change. So in a workflow with some existing nodes, if you add a node from the library it would always reload the module before adding the node to the workflow and now you have "old" nodes and "new" in the same workflow that want to type hint to the same classes, but no longer cna.

[Tara-Lakshmipathy]

Ah, I see what you mean. Yes, I experienced that issue too. My simple workaround was to delete the "old" nodes individually from the viewport. Still hadn't gotten around to replacing existing nodes in the workflow with the "new" versions yet.
Similar story with the macros as well, hadn't gotten around to replacing the nodes in the workflow with the newly created macro. So adding the macro from the node library would mean the macro exists as well as the sub-nodes that were used to create a macro.

[pmrv]

Honestly, I'm not going to replace a full workflow node by node, especially since caching and saving/loading are working now. It's much faster to save a workflow, restart the kernel and load it.

[Tara-Lakshmipathy]

In the old way of reinstantiating the workflow for every action, this was done on your behalf and all the nodes that did not have their codes changed did not pose an issue anyway. So only the ones that had their source code changed had to be replaced.

But the refresh button is useful for another thing: populating the node library with newly created nodes (not yet in a workflow) without having to re-instantiate the widget. Would be useful when downloading new nodes from the node-store when needed without having re-instantiate the widget all the time.

[Tara-Lakshmipathy]

Basically, what I'm getting at with all this is that there are situations when reinstantiating the workflow would be useful. So we should not try to get rid of it altogether. Doesn't have to be done before DPG, but I would definitely eventually have some feature in there that let's me do that.

[Tara-Lakshmipathy]

Another final comment: I'm currently working with some experimentalists at BAM for the GUI. They have no idea of what a kernel is to restart it. They also don't know what it means to reinstantiate the widget. So my aim is to eventually make pyironflow appear to interface with the file system (for caching and reloading) like excel or powerpoint. So, in the long run, I consider restarting the kernel as off limits 😂