Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distinguish between string and task name #42

Open
multimeric opened this issue Aug 15, 2024 · 1 comment
Open

Distinguish between string and task name #42

multimeric opened this issue Aug 15, 2024 · 1 comment

Comments

@multimeric
Copy link

multimeric commented Aug 15, 2024

Currently the napari workflow format uses strings as arguments, either to name tasks that they depend on, or as literal strings. If the workflow is "complete", ie all the dependencies are specified, then this is not a big issue: any strings that correspond to a task name are assumed to be dependencies, otherwise they are strings. However, it does mean that any determination of inputs is impossible. In the following task, I have one task (strlen) that just calculates the length of "some_string" and has no inputs. I also have dimensions which returns the shape of an unspecified image. However if I try to work out which inputs the workflow needs to run, roots() thinks that both are inputs:

from napari_workflows import Workflow
from numpy import shape

w = Workflow()
w.set("dimensions", shape, "input_img")
w.set("strlen", len, "some_string")
w.roots()
['input_img', 'some_string']

The only true result here should be input_img.

I think it would be better to use a special type to either mark literal strings or task connections, in order to disambiguate this scenario. For example something like this would be ideal:

from napari_workflows import dependency

w.set("dimensions", shape, dependency("input_img"))
w.set("strlen", len, "some_string")
@haesleinhuepf
Copy link
Owner

Hi @multimeric ,

awesome, thanks for the feedback! I have no idea if this technically feasible. Under the hood we are using dask graphs and strings as keys because napari layers have string names.
Saying that, if you could implement your proposal in a way that this plugin still works with napari and code generation with the napari-assisrant, I'd be happy to merge your pull-request.

Let me know if I can do anything to support you!

Best,
Robert

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants