Differences from magicgui?

[ctrueden]

I'm wondering how this project compares to magicgui, a parameter-generation Python library in production use by napari and other software in the Python ecosystem. Were you aware of magicgui when you wrote EZInput? If so, it should be mentioned in the publication branch's paper.md; or if not, might it be possible to join forces?

[brunomsaraiva]

Hi @ctrueden, we were aware of it but only on the napari side, its even what we use for our napari plugin of NanoPyx.
After checking it again, I see that magicgui also supports jupyter notebooks which does overlap with our project implementation. Main differences are.

1. we also support CLI as an interface
2. jupyter notebooks can be executed through the CLI if they were prepared using EZInput.
3. EZInput has "memory" of the last used parameters
4. enables export of simple yaml parameters files that can be used to share the exact analysis pipeline with other users.

We should defintely add a mention to it in paper.md, it was an oversight on our side that I'll fix there and on any potential future manuscript submission.
Regarding joining forces, we would be happy to have chat about it, it does seem like we complement each other features quite well.

Best,
Bruno

[ctrueden]

Thanks for the detailed reply, @brunomsaraiva!

I had a brief chat with Claude.ai about this. It pointed out that EZInput is an imperative approach vs. magicgui's declarative approach, so they are fundamentally different, which is fair. I personally prefer the declarative style for backend-agnostic typed input/output parameters, as I'm sure is unsurprising given how I designed SciJava script parameters.

Claude did suggest a couple of possible areas of collaboration, though:

1. EZInput as a CLI adapter for magicgui functions — the most natural fit. A @magicgui-decorated function already knows its parameter types; EZInput could provide a way to run it in a terminal by routing to EZInputPrompt. This fills magicgui's biggest gap without either project rewriting its core.

2. EZInput using magicgui as its Qt backend — EZInput currently has no desktop GUI mode. It could add a third backend (alongside Jupyter and prompt) that delegates to magicgui when Qt is available, inheriting all of magicgui's widget richness and napari compatibility.

Both of these make sense to me, but of course are only worth doing if we actually need a CLI-based magicgui backend and/or support for EZInput harvesting in Qt apps. 🤷

Just food for thought! Feel free to close this issue whenever.

CC @tlambert03