Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

dalthviz
Copy link
Member

@dalthviz dalthviz commented Aug 8, 2024

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).

plugins_disclaimer

  • Current PR state:
Theme Preview
Dark plugins_disclaimer_label
Light imagen

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

Notes

* 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

@dalthviz dalthviz self-assigned this Aug 8, 2024
Copy link

codecov bot commented Aug 8, 2024

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
Copy link
Member Author

dalthviz commented Aug 9, 2024

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:

plugins_disclaimer_label

  • Using the currently available popup widget:

plugins_disclaimer_popup

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

plugins_disclaimer_dialog

@dalthviz
Copy link
Member Author

dalthviz commented Aug 13, 2024

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

@goanpeca
Copy link
Contributor

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

Thanks for working on this

Copy link
Contributor

@goanpeca goanpeca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@dalthviz
Copy link
Member Author

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

imagen

Let me know if something else is needed!

Copy link
Member

@jni jni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

kephale commented Aug 14, 2024

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
Copy link
Member

psobolewskiPhD commented Aug 14, 2024

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
Copy link
Contributor

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

@jni
Copy link
Member

jni commented Aug 15, 2024

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
Copy link
Contributor

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
Copy link
Member

jni commented Aug 21, 2024

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?

@dalthviz dalthviz marked this pull request as draft August 22, 2024 14:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add one-time disclaimer about the 3rd party nature of the plugins and its security implications
6 participants