Add an extra question for the template to ask if the plugin will be shared with hub

[goanpeca]

In the migration of plugins to conda packages, severla plugin authors have shared messages similar to (paraphrasing here)

• "The plugin was publish as a convenience for the lab or internal staff only"
• "The plugin was not ready to be shared publicly""
• etc...

I would suggest adding a question in the cookiecutter to ask the plugin developer something like:

"Is you plugin ready to be shared with the rest of the world openly via napari-hub" or similar? [N] And perhaps make it no as a default?

---

Also something regarding the public state of the repo containing the source code.

Do we enforce plugin developers to have public repos? (this is probably a separate question) Some of these repos are not public, sometimes by accident and authors reply. Sometimes authors never reply, or we do not have github (or gitlab?) handles available to ping as the plugin information is limited.

Pinging @napari/core-devs

[jaimergp]

+1000

I'd ask something like:

• "Is the plugin ready for publication on napari-hub? This should only be considered for actively developed projects or well-tested ones."

I understand we might be using the classifier as an easy marker to find napari plugins, so maybe we need two markers: the generic one to say "this is a napari plugin" and then a more specific one to say "this should be considered for publication in napari-hub".

[Czaki]

Did someone upload a private project to pypi?

[goanpeca]

Several napari plugins on pypi do not list a repo or point to a repo url that gives 404

[Czaki]

But still code is avaliable on pypi.
In situation when --extra-url is avaliable.

[goanpeca]

Sometimes only wheels are available which do not work for conda recipes as we need source either from tarball or github/gitlab/etc. release. But I think we are moving the conversation in a different direction from the original issue, and that is that any use of the cookiecutter should probably not have a default napari classifier as there are already packages that were created as a test, (napari-cookiecut, napari-hello... )

[Czaki]

I agree. If you make such PR I will review it.

[DragaDoncila]

We've had this conversation before a couple of times. The key issue is I think people will forget to uncomment their framework classifier when releasing, be confused about the fact that it doesn't show up in the installer/on the napari hub, and will then have to do another release to address that. But I definitely agree that having it there without asking is not good because there's every chance the plugin is being built for limited use or even just for testing/learning purposes. I don't think it makes sense necessarily for the Framework classifier to be removed, since it is a key part of making a napari plugin.

The visibility field was implemented in npe2 for this purpose. Maybe our question should be:

Set plugin visibility to hidden? It won't be public in the plugin installer or on the napari hub until you're ready

And the default would be yes, hidden. This would require the napari-hub and napari both to be updated to read this field (rather than relying on the hub specific one), but I think is overall better than just removing the Framework classifier.

[jni]

Huge +1 to Draga's comment. I absolutely don't want to gatekeep the hub with "should only be considered for actively developed projects or well-tested ones." But setting visibility to hidden by default is a good idea.

[tlambert03]

Something I haven't seen mentioned is more of an "educational" message about what makes for a good plugin, vs just modifying your own napari experience by directly using window.add_dock_widget or making a keybinding, etc.

However we got here, I think there is far too much of a community perception that "plugins are how you customize your experience"... when in fact the message should be "There are many non plugin ways to customize your experience, once you know that you have a thing that should be shared with others, consider converting it to a plugin".

(in other words, by focusing on number of plugins as a "metric of quality", a major point has been missed about directly using the api).

So, you could consider placing some information about that front and center (that is, I think you should actively try to decrease the growth)