Add an optional disclaimer message widget related with 3rd party nature of the plugins

[dalthviz]

Description

Closes #93

• Initial preview of a possible widget and the way it would interact with multiple launches of napari (should only be shown once per napari settings instance).

• Current PR state:

Theme	Preview
Dark
Light

Also, the final widget should be dismissible (even without closing the plugin manager dialog, you should be able to close/hide it)

Notes

• Position, style/type and text of the widget that shows the message to be defined

  • Initial alternatives exploration at Add an optional disclaimer message widget related with 3rd party nature of the plugins #95 (comment)
    • label but that can get dismissed with a button + some style option selected

• To show the message only once a basic config logic was added (using configparser and creating a napari-plugin-manager.ini file over the user home directory under a .napari-plugin-manager folder)

* This requieres changes over the napari side. The behavior that can be seen above (the message is displayed only once per napari installation/settings instance) can be achieved by adding to the napari plugins settings a flag related with the visibility of the disclaimer message and doing some changes to the logic at https://github.com/napari/napari/blob/dd0a3c6455e6455a80e87f4481437f02c9a0c356/napari/_qt/_qapp_model/qactions/_plugins.py#L27-L37 (_show_plugin_install_dialog function) so with something like:

def _show_plugin_install_dialog(window: Window) -> None:
    """Show dialog that allows users to install and enable/disable plugins."""

    # TODO: Once menu contributions supported, `napari_plugin_manager` should be
    # amended to be a napari plugin and simply add this menu item itself.
    # This callback is only used when this package is available, thus we do not check
    from napari_plugin_manager.qt_plugin_dialog import QtPluginDialog

    show_disclaimer = get_settings().plugins.manager_disclaimer
    QtPluginDialog(window._qt_window, show_disclaimer=show_disclaimer).exec_()
    get_settings().plugins.manager_disclaimer = False

To check locally the behavior here a branch with the mentioned setting addition and plugin dialog instanciation change over the napari side: dalthviz/napari@33f8707

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.78%. Comparing base (7ab6096) to head (2dc360b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #95      +/-   ##
==========================================
+ Coverage   93.57%   93.78%   +0.20%     
==========================================
  Files          10       12       +2     
  Lines        1822     1883      +61     
==========================================
+ Hits         1705     1766      +61     
  Misses        117      117              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dalthviz]

After getting some feedback, couple of alternatives for the actual widget that should show the disclaimer message:

• Using a label but that can get dismissed with a button + some style to make it more visible and under the available plugins label/section:

• Using the currently available popup widget:

• Using an independent modal dialog on top of the plugins dialog:

[dalthviz]

Note: An initial selection for the first option (dismissible label + button was done). Commit f27b75b adds the changes for that option

[goanpeca]

Hi @dalthviz, option 1 looks the best to me :)

Thanks for working on this

[goanpeca]

LGTM, but could you post an image of how it looks with the na;ari light theme @dalthviz ?

[dalthviz]

Updated the OP to show how things look with the PR current state when using the light theme, but just in case:

Let me know if something else is needed!

[jni]

Hi folks, thanks for your work here but personally I don't love this at this stage of the project. Personally I don't feel comfortable even vouching for first party code, which is sort of implied by this approach. 😅 I would rather put some documentation about this in the plugins docs and on the hub.

I'm happy to be overruled here (CC @DragaDoncila @kevinyamauchi @kephale) but in the meantime it just seems like overkill. Like, pip itself doesn't warn you, so why should we?

At some point in the next couple of years, when the bundle is a major distribution channel for napari, we can perhaps revisit the idea. (And maybe on installation we can have this note.) But in the meantime, it feels like adding "caution: contents may be hot after heating" to our portable coffee cups...

[kephale]

I'm not here to overrule, but I can explain the reasoning:

Since napari-hub and the plugin list are updated based on framework classifiers that are declared by the package, it is pretty trivial for random things to add themselves to the plugins list.

My bigger concern with this has already been stated: this implies that there are vetted plugins and I don't see the person-power to do that reliably right now.

That said, it is standard practice with most packaging things to separate 3rd party and "official" packages (again I don't volunteer us to take on curating "official" plugins), and having our source of plugins that are arguably partially endorsed (e.g. the napari plugin manager lists them from within napari as napari plugins) be 100% public feels like using http over https.

[psobolewskiPhD]

I'm OK with something that makes clear that plugins are 3rd party and not napari things. The line does blur with console and svg (which is first party but only partially functional as read isn't implemented). Further, like 80% of plugins are named napari-blah so ours (napari-console, napari-svg, etc.) don't stand out in any way.
I think this is more important in the bundle context too, where one can expect all the interaction with plugins will be via the GUI installer.
Of the 3 options above I like the first and maybe tweak the text to something like:
"Available plugins are 3rd party, are not vetted, and may be unmaintained."

[jaimergp]

For broader context, the inspiration for this rationale is https://aur.archlinux.org/ (as stated in the linked issue).

[jni]

Ok but that is an OS level package manager. Again, on PyPI itself, no such warnings. Fiji (the software most comparable to the napari bundle) does not have any such warnings. 🤷 The community seems to be mixed on best practice here (any warning on conda-forge? I can't find one), and little wonder, since we live in a world of absolute warning fatigue, where we are conditioned to dismiss them without reading them — they are just another annoyance.

I think a warning on the hub home page, or even in the documentation on plugins, would be a more effective way to handle this.

[jaimergp]

Again, on PyPI itself, no such warnings. [...] any warning on conda-forge? I can't find one

These are community repositories for packaging. Their documentation covers the fact that anyone can upload arbitrary packages (or in the case of conda-forge, submit arbitrary review requests).

since we live in a world of absolute warning fatigue, where we are conditioned to dismiss them without reading them — they are just another annoyance.

I get that part. What we are trying to do here is to

I think a warning on the hub home page, or even in the documentation on plugins, would be a more effective way to handle this.

We don't have access to the napari hub, and I'm not sure folks downloading plugins are reading the contributing plugins guidelines. But maybe there's a good tutorial that a lot of folks read and that's where the warning should be?

I don't feel strongly about having a disclaimer or not, just wanted to have users know they should be wary of they click onto. As long as we fulfil that, I'm ok.

[jni]

We don't have access to the napari hub,

This might change in the near future. 😉 Can we put this on ice for a couple of months and revisit?