-
Notifications
You must be signed in to change notification settings - Fork 6
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
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
After getting some feedback, couple of alternatives for the actual widget that should show the disclaimer message:
|
Note: An initial selection for the first option (dismissible label + button was done). Commit f27b75b adds the changes for that option |
Hi @dalthviz, option 1 looks the best to me :) Thanks for working on this |
There was a problem hiding this 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 ?
There was a problem hiding this 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...
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 |
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 |
For broader context, the inspiration for this rationale is https://aur.archlinux.org/ (as stated in the linked issue). |
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. |
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).
I get that part. What we are trying to do here is to
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. |
This might change in the near future. 😉 Can we put this on ice for a couple of months and revisit? |
Description
Closes #93
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
To show the message only once a basic config logic was added (using
configparser
and creating anapari-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: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