Functionality to ignore a plugin

[adamltyson]

Is your feature request related to a problem? Please describe.
I'm developing a few plugins, and often new ideas take over, but old plugins remain on PyPI. I'd like to ensure that those stale plugins are not visible on the napari hub, potentially confusing users (e.g. should they use napari-cellfinder or cellfinder-napari?)

Describe the solution you'd like
Some way of easy marking the repository as not for the napari hub, e.g. .napari/.hub-ignore

Describe alternatives you've considered
I could remove them from PyPI, but I'd like to keep them there to support existing projects.

[neuromusic]

Thanks for bringing this up, @adamltyson !

I'm curious if there's existing functionality on PyPI that would support this need. I'm thinking of features like "yank" or adding a "deprecated" trove classifier.

[tlambert03]

fwiw, "yanks" apply to releases, not projects. The deprecated concept might work a little better... there's no "deprecated" trove classifier (and you're not allowed to make them up) ... but you could use Development Status :: 7 - Inactive. The possibility remains though that the project itself isn't inactive though... let's just say that they no longer wish for the project to be their napari plugin?

I suppose they could remove the napari trove classifier from their metadata, but the previous releases would still show up presumably (it might just be that the "version" shown is the last one that had the napari classifier?). Definitely potentially tricky stuff. I think that, inasmuch as you're already providing a .napari file for various napari-hub specific overrides, a .napari/.hub-ignore option makes a lot of sense here.

[neuromusic]

thanks @tlambert03 ... yeah, "Development Status :: 7 - Inactive" is what I was thinking of

[neuromusic]

For the June release, we are planning to have an "exclusion list" just in case a plugin shows up that is malicious or violates the napari code of conduct for some reason... so we'll already have some of the logic in place. As a short term fix, we might be able to manually add @adamltyson's plugins to that list.

But for the long term, I really like the idea of giving plugin devs a bit more control over the "discoverability" of their plugin in the hub (and the napari UI, for that matter)

[neuromusic]

inasmuch as you're already providing a .napari file for various napari-hub specific overrides, a .napari/.hub-ignore option makes a lot of sense here

I could also imagine a flag in the .napari/config.yml that permits 3 levels of "visibility" on the hub

• Public (default, fully visible)
• Hidden (listing page exists, but doesn't show up in search. useful for pre-release development)
• Disabled (no listing at all)

[adamltyson]

you could use Development Status :: 7 - Inactive. The possibility remains though that the project itself isn't inactive though... let's just say that they no longer wish for the project to be their napari plugin?

This is pretty much it. The project may still be ongoing, but we don't necessarily want it to be "found" as a napari plugin. Maybe it was once a plugin, and now it's a standalone tool, or maybe we're just supporting it internally.

I could also imagine a flag in the .napari/config.yml that permits 3 levels of "visibility" on the hub
Public (default, fully visible)
Hidden (listing page exists, but doesn't show up in search. useful for pre-release development)
Disabled (no listing at all)

I like this idea, especially as we can gradually move between the levels of visibility.

[adamltyson]

Hi @neuromusic, as discussed. As a temporary measure, could you hide/block the napari-cellfinder and napari-brainreg plugins from the napari hub? Thanks!

[neuromusic]

👍

Yep, will do!

[neuromusic]

🎉 We've implemented this in #268