Done!

To investigate - jupytext, quarto

@gnodar01 @rajavishah to be clear, just because Nodar mentioned ipywidgets in our last meeting - was definitely NOT thinking that fancy. Just something with a couple of markdown cells of things like credits and citations, one cell that defines a bunch of variables, and then one cell that runs the execution command with ! . So it would look something like the below. Obviously, dream as big as you want, but I was thinking something EXTREMELY simple.

Done!

#110

@kenibrewer had some thoughts on how we might think about this for Nextflow/nf-core

Yes! I do indeed have some thoughts!

Best practices for Nextflow include packaging individual tools into modules. These can then be reused across multiple workflows and pipelines.

The biggest and most commonly used source of modules is the modules library maintained by nf-core. Once a module is integrated into that repo, they can be installed in pipelines using the cli command nf-core modules install <tool_name>. I think most of the linkml and jinja templating should be able to write most of what may be needed for a module to conform to nf-core standards. Some anticipated pain points would be:

• There may be additional documentation requirements beyond what's available in LinkML
• There is a requirement for at least one runnable unit test (with paired test data).
• nf-core has certain linting requirements
• Changes to modules would have to go through a pull-review process

An alternative that would be easier to automate would be creating a separate nf-core style modules repo. This would allow module changes to be merged automatically without pull reviews, testing, and linting/documentation requirements. The disadvantages would be that the lack of testing means that there's less of a guarantee that the module actually functions as promised and likely less reach than building within the established ecosystem for open-source Nextflow builders.

Personally, I think the value of getting these imaging tools into the mainline nf-core modules repo is very high. Perhaps it might be possible to try having the LinkML automatically open pull request against nf-core modules which might perhaps be tagged with an imaging related tag. Then slack/github could ping me and hopefully other volunteers from nf-core who could review the PR changes and hopefully bring them to completion?

Thanks, that's awesome!

I'm not too worried about points 1,3, and 4 being dealbreaking issues; unit testing I think is the biggest obstacle, and somewhere that, as of now, we had decided we weren't planning on going, since we do not want to be the arbiters of "does your tool work". There's then 2 sub-options that link to that (beyond just your idea of a separate repo, which I suspect will end up as least-worst):

• Shitty testing - we have one (or a suite of no more than 5 max representing a few archetypes of use cases) sample image(s), our CI/CD runs the input, and then submits the "test" as the output. It will ensure that output is made, but not that output is good.
• Shitty testing with then ad-hoc QC; we make a separate repo with the shitty testing versions, and then for tools we ourselves use (or anyone else wants to) get validated with real hyperparameters/tunable things and then sent to the real nf-core repo.

I love the idea of making these tools more accessible to a broader audience, I just don't want our interfaces to be writing "time spent in QC" checks that my team's availability can't cash, especially if/when we have dozens of algorithms in the interface - even if each one only takes 15 minutes, that will (hopefully) add up.

Gradio was actual the original interface that inspired creation of the bilayers project - a former postdoc used it to help less-computational collaborators access a custom neural network he'd trained for them and then made a demo version; that became one of the seeds of the whole thing!

Dash apps are great, we'd be happy to have a PR if it's possible to programmatically use our spec to develop them. I don't know anything about Zephyr or how it would fit in!

@TimMonko I think had some thoughts here!

Thanks Beth. I see previously that @gnodar01 listed magicgui. Based on his description yesterday of how the CellProfiler implementation works, I think a joined magicgui-napari approach will succeed in many goals because it can generate the GUI via a declarative approach. In addition you would be able to use these magicgui widgets via jupyter equivalently to the napari method (and some other frontend I cna't think of) so it would solve other ways of serving as well.

You can see what I think is a clever declerative approach to GUI building in this new project I started https://github.com/ndev-kit/ndev-settings/. I believe you serializethese models via JSON right now, which could be evaluated in a very similar way via magicgui, allowing you to create widgets on an as-needed basis per model. https://github.com/ndev-kit/ndev-settings/blob/c5970fbedaa59d1fa1b4c8e559e8387f963b81c1/src/ndev_settings/_settings_widget.py#L27-L66

WRT Huggingface, directly above, streamlit is the other interface supported by it via streamlit spaces.