Plugin management system

[jni]

• [x] based on git
• [ ] every function call is recorded into a script that acts as a 'reproducible log'
• [ ] wrap the script in its own function
• [ ] automatically push to remote repo
• [x] automatically manage versions: git tags if available, or git hash otherwise
• [x] add plugins by adding URL of git repo
• [x] the core of Napari is just the minimal plugin system, everything is plugin based, even the plugin core, this way we have a unified way to push updates to users. Users can also add their own user defined plugins, and first class contributions can be added to the official distribution.
• [x] Each repo has a 'configuration' file that describes the plugins present in the repo, what kind of plugins these are (viewer, processing, analysis, ... ), how and where they get integrated into the GUI menus, and where to find the 'entry point' python file within the repo.
• [x] We need some sort of 'interface' scheme to normalise how the host python code will interact with the plugin code... What is the pythonic way to do it?

[kne42]

I assume that we will also be creating our own environment then?

[jni]

@kne42 Ah yes, this is a good point. And an interesting one. I think separate environments will be tricky to manage. You'd have to do inter-process communication, and plugins would be second-class citizens, because you couldn't match the performance of running in the "app" environment. Perhaps we should explicitly say which packages we are shipping with the app, and plugins can add packages but only if they don't conflict with the base ones, in the conda-forge sense of "conflict".

[royerloic]

For now we have to define a basic but relatively exhaustive set of dependencies that would cover 90% of needs. Late on, we can figure out a way for plugins to play well together. This has not been solved in FiJi for example.

On 4. Jun 2018, at 23:12, Juan Nunez-Iglesias notifications@github.com wrote:

@kne42 https://github.com/kne42 Ah yes, this is a good point. And an interesting one. I think separate environments will be tricky to manage. You'd have to do inter-process communication, and plugins would be second-class citizens, because you couldn't match the performance of running in the "app" environment. Perhaps we should explicitly say which packages we are shipping with the app, and plugins can add packages but only if they don't conflict with the base ones, in the conda-forge sense of "conflict".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Napari/napari/issues/3#issuecomment-394593441, or mute the thread https://github.com/notifications/unsubscribe-auth/AByMknqOfxKUq5cIp780yqOObdd6jrJNks5t5iFZgaJpZM4UYKpd.

[royerloic]

We can use the GitPython lib: http://gitpython.readthedocs.io/en/stable/index.html

Here is an example how to pull: https://stackoverflow.com/questions/20073873/how-to-checkout-a-tag-with-gitpython

[kne42]

Thanks for the pointers! I'll get started on this now :P

[kne42]

I think we should create a cookiecutter for plugins similar to what Jupyter has set up.

[royerloic]

Great idea!