-
Notifications
You must be signed in to change notification settings - Fork 5
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
META: Decouple plugin-manager from napari #59
Comments
Gave this an initial check and from the UI part (widgets definitions under
Also, there are some widgets that are being used which come from napari like Some other general elements that probably should be encapsulated into a method to override/should be marked with something like Could it make sense to start doing small PRs (like to encapsulate the translation logic or the |
I do not see here any topic about generalization of plugin API server, like https://github.com/napari/npe2api Did you plan to only document the REST API required by generalized plugin manager? |
Thanks for the feedback! I would say in my initial idea a definition of what info is needed for the plugins will be done but I don't think that documentation would follow a REST API structure. I would say the work I was thinking of is going be closer to a well defined abstract class which has methods that need to be implemented. Following that, I was thinking on a base class definition which requires the developer to implement several things like a way to query plugins when extending it (which in the case of the napari class would use the current logic using the napari-plugin-manager/napari_plugin_manager/qt_plugin_dialog.py Lines 1101 to 1115 in dbcd362
However, other implementations could extend the base class and make the query method to query things from a file or define a constant/variable with the info needed without the need of querying a web service. I think that's the scope of this work (at least from the GUI part) but maybe I'm missing something? Maybe the scope here is also to define the API a web service that retrieves plugin info needs to follow to work like the |
Yep, that's what I had in mind too. napari happens to have the npe2api service (and we can document what we are doing there if someone wants to reuse the same approach for their stuff), but in principle users should define their own list population logic. In the future, if folks are really interested in the npe2api-like stuff, we could think of providing a 2nd level base class that streamlines the API querying but I think that's a second step, not the first one. |
Other dev teams have expressed interest in using our plugin manager in their ecosystem. To that end, we offered to provide a plugin-manager UI that is uncoupled from napari as much as possible. The end goal would be a
napari-plugin-manager
that depends and extends a hypothetical, application agnosticplugin-manager-dialog
(name tbd).To do:
plugin-manager-dialog
napari-plugin-manager
into two packages (still in the same repo) following the design proposed above. These two steps can happen iteratively (implementation informs design and viceversa)The text was updated successfully, but these errors were encountered: