Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This aim's to address one of Joerg's concerns in #189:
This issue runs headfirst into the tension between ironflow's objective of being functional and the fact that pyiron jobs are really, really not functional. Specifically, the problem here lies in comparing the name+input of an ironflow node to serialized input of an existing pyiron job of the same name. This might be straightforward if we could hash the input data as proposed by Sam, but right now we still can't.
So the current setup was intended to rigidly ensure that from within ironflow the user could not not tamper with any pyiron jobs that they had not themselves created. For example, deleting jobs (with the job node's
remove
button) would only work if it was deleting a job that node had already created that session. Imagine this restriction were not in place and that we had two calc nodes using the same job node; we could run the first, then go over to the second and remove the first's job, silently corrupting its data!In the long run I think there are good solutions to this, ranging from a more rigorous interface that exploits IO hash comparisons right over to a better alignment of the underlying pyiron model with ironflow in terms of how data storage is treated (i.e. some of the directions we're currently heading with "pyiron 1.0").
Right now though, the criticism is well taken that job management is a huge pain. As a sort of compromise, here I extend the
Project
node to give an interface for job deletion. This is "restricted" behind anenable_remove
boolean input, so users can't just accidentally or hastily hit theremove
button and start killing things -- IMO this is analogous to the previous restriction that the user had to type something likegui.selected_node.outputs.values.project.remove_jobs()
, but now it's a little more convenient and exists inside the gui framework.The node now looks like this:
![Screen Shot 2023-04-14 at 14 14 25](https://user-images.githubusercontent.com/20283329/232158560-8e3daca2-a378-4268-ad46-0e550739ed32.png)
And if you open the control panel these are the defaults:
![Screen Shot 2023-04-14 at 14 14 32](https://user-images.githubusercontent.com/20283329/232158578-a6c6b013-a9f3-49e6-9a6b-e1b9ed5dc9e2.png)