NapariMPLWidget as standalone

[Chris-N-K]

Hi, nice work you did here.

What would you think about a standalone version of the NapariMPLWidget and other transferable parts of your plugin. This standalone version could then be imported by other packages / plugins to use without your whole plugin as dependency?
Something like napari-matplotlib-base or similar?

I used your implementation of the FigureCanvas in my plugin but if I don't want to simply copy the code but import your work, your plugin has to be installed as well. I'm not sure if this is in the interest of the end-users. They might just want to have one specific functionality.

If you want to take a look I provide the napari-time-series-plotter widget.

[dstansby]

Sorry for the slow reply!

Is this issue you don't want napari-matplotlib appearing in the plugin menu when your users install napari-time-series-plotter? If so I think we could definitely look into providing a napari-matplotlib-base, but it would be quite a lot more work to maintain two packages, so I definitely don't have the time to do it in the near future.

[Chris-N-K]

Hi thanks for the reply.

Yes exactly, so that other plugins could use your nice implementation of the MPLCanvas without adding more than the user might want to napari, to keep confusion low.

If you like I could help maintain such a package.

Best Regards,
Chris

[dstansby]

👍 sounds good to me, thanks for the clarification. Had a very quick think, and maybe the way to do this is:

• have a configuration file that has a flag to turn on or off having the napari-matplotlib widget present in the napari plugin menu
• make a napari-matplotlib-base package that installs napari-matplotlib with this flag set to not show napari-matplotlib in the plugin menu

This way all the code lives in napari-matplotlib and we don't have to worry about testing across two different repositories etc.

Do you think that sounds feasible? Or have better ideas? (I really didn't spend long thinking 😄) Let me know what you think!

[Chris-N-K]

Both solutions sound good. I guess the big question would be how easy is it to configure case one as dependency.
Thus, I would lean to the second solution.
I would suggest to integrate it in de deployment job already included in the napari-cookiecutter test_and_deploy.yml file. This way both packages are created upon tagged push and uploaded to PyPi. Should make the second solution low maintenance.

[dstansby]

Just thought a bit more about this, and I think the only way to do this is to have separate repositories, but I think that's fine.

[dstansby]

So I started work on this, and I'm revisiting doing it. It's a lot more work maintaining two separate pacakges and repositories, and as far as I can see the only advantage is that users don't have napari-matplotlib appear in the napari plugin menu when it's installed as a dependency of another plugin. @Chris-N-K apart from this are there any other reasons why you would like the base widget to be available in a separate package?

[Chris-N-K]

@dstansby thanks for the ongoing work on this plugin.
I thought about it for some time and I agree with you that the only real benefit is the plotting functionality of napari-matplotlib not appearing in the plugin menu. This might be nice as the plugin access can be cluttered and might be confusing, but probably doesn't justify the effort of maintaining a second package and repository. Plus your plugin is lightweight in it's dependencies.

Could completely understand if you drop this.

[dstansby]

Thanks for the feedback - in that case I think we'll drop this. Thanks for opening though, and please don't hesitate to open any more suggestions or issues in the future!