-
Notifications
You must be signed in to change notification settings - Fork 19
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Functionality to ignore a plugin #15
Comments
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. |
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 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 |
thanks @tlambert03 ... yeah, "Development Status :: 7 - Inactive" is what I was thinking of |
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) |
I could also imagine a flag in the
|
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 like this idea, especially as we can gradually move between the levels of visibility. |
Hi @neuromusic, as discussed. As a temporary measure, could you hide/block the |
👍 Yep, will do! |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
orcellfinder-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.
The text was updated successfully, but these errors were encountered: