Plugin parameters

🚀 Feature

As raised in zulip and elswhere, we need a mechanism to pass arbitrary parameters to plugins (beyond those declared in the hook specification). Currently, napari_plugin_engine (like pluggy) does not allow calling hooks with arbitrary kwargs (it’s not an error, but they are not passed on) … but we can probably come up with an acceptable way to open that up. The main things to decide are

1. what sort of API do we want to support on the napari side? Currently, calling viewer.open(**kwargs) passes all additional **kwargs to the respective add_* method. So we’d need to either add a plugin_kwargs={} argument (probably better), or do some clever separation of of kwargs (probably worse). I also think it would be reasonable to only accept plugin_kwargs when also providing a specific plugin.

2. haven’t thought about the hook calling side as much, but the lines where kwargs not specified in the hook specification are stripped are right here… so that’s a place to start.

[tlambert03]

I just meant what is in our mission statement: “providing GUI access to all critical functionality so napari can be used by people with no coding experience.”

I guess it’s the “critical” part that’s a bit open to interpretation 😃 … The gui is of course super important, and I definitely agree that we should be cognizant of how any particular new design might ultimately play with the GUI (and i wouldn’t want to shoot ourselves in the foot with a built-in incompatibility) … I just didn’t see gui-only use as the primary goal.

[jni]

make things really simple and accessible for the GUI only user - which has always been a primary goal of napari

I just want to correct the history a little bit here… At least from my perspective, napari was first and foremost a viewer for the scientific Python ecosystem. Making that ecosystem accessible to non-coders — that came at least a tick later. And I want to emphasise that although it is now a primary goal of napari, I don’t want it to come at the cost of napari becoming bloated or inflexible as a Python library.

---

Edit: Upon further reflection I think I spoke too quickly re the history. (It was a pedantic correction and an incorrect pedantic correction is just terrible, so I feel compelled to, ahem, correct it. 😂) Probably Loic and I did discuss that our then-hypothetical-and-unnamed Python viewer could be used as a front-end for skimage and beyond — not having one has been a source of frustration for me because I can’t get biologists to use my stuff without first going through weeks of Python training! Also, @tlambert03 you might recall that when I first asked you to join napari it was because you wrote to me asking whether it was a good idea to make a GUI to make Python processing accessible for non-Python users, and I said it was such a good idea we were already working on it! 😂

I guess my response above came from the fact that de facto, napari has become insanely useful and popular as a scientific Python viewer, and we should work hard to preserve that utility and popularity even as we expand its use to the non-programmer, GUI-only side.

/edit

---

In particular in this discussion, I lean slightly in favour of being more permissive than restrictive initially. We are in alpha and I think the current batch of people building on napari would be happier to have us provide more facilities sooner and let them experiment, even if at first it means a bit more pedalling to keep up with our API, rather than to wait for us to design “the perfect system” and then realise it can’t quite do what they want anyway.