# Plugin Sustainability Working Group Meeting Notes

## Thursday 2026/01/07

Attendees: Brian, Tim, Grzegorz

### Agenda

- Happy new year :)
- How to keep people from pinning napari in their plugins?
- GB proposes having some kind of lock file
- Brian asks about not using a qt backend
- default dependencies should just us `PyQt`
- any backends hould be put in extras
- BN now ships with lock files
- GB brings up meta-packages for pypi
- BN talks about swapping around nd
- how to map overlapping labels
- TM asks BN to consider writing a blog post abuot pixi
- getting people to install pixi is a barrier
- did i2k online with pixi and appose
- GB talkinga bout generation of code for napari installer
- so we can expose the bundle + plugin shipping
- how far are we from this process?
- need documentation
- decision on how to do the certificate signing for OS's
- --no-verify would be helpful
- what is pre-commit vs ruff check
- we should document the packaging stuff better
- how to use LLMs well
- use it for formatting fails (like ruff check/format)
- use it for explaining CI fails
- BN tries to use the agent sparingly, instead using other modes like ask or edit or whatever
- so we want to expose how to use AIs beter

## Thursday 2025/12/04

Attendees: Tim, Draga, James, Juan, Carolyn

### Agenda

- Discussing skan
- skan has two napari widgets
- one has a good way to return a `LayerDataTuple`
- the computational code lives outside the widget, and it's nice to reason about the widget flow
- in ndev, Tim has code that does a similar skeletonization thing but returns valued labels layers
- and has a tool for eroding different labels that touch to stop them from touching, before skeletonization
- Juan happy to take the contribution into skan
- OSError with two labels layer and a shapes layer, eventually...
- How do we manage the different levels of contribution that a package might be willing to accept
- some people want just bug reports, some people want bug fixes or a small new feature, whereas others want to fully collaborate on a project
- are plugin developers experiencing a mismatch between contributions they want and what they're getting?
- TM: some folks have said they want to contribute but there's not that much activity on the repo. Sometimes people have e.g. updated plugins to use new python etc. but they keep it local, they don't open the PR because they don't know if the contribution would be welcome
- talking again about keeping a community org where plugins can go that need maintainers
- difference between napari org taking on maintenance of this vs. the author isn't maintaining it but is open to someone else maintaining it
- Draga is concerned about diffuse responsibility
- napari contributing.md is being populated from GitHub workflows, so we need to fix that
- issue open
- Reorganizing plugin docs
- Beginner vs advanced building a plugin
- Draga thinks doing "your first plugin" PRIOR to the napari-plugin-template is useful
- Tour of the files what vs why/how
- Need better: where does metadata bits come from
- chanzuckerberg/napari-hub "A plugin developers guide to the napari hub"
- https://github.com/chanzuckerberg/napari-hub/wiki/Plugin-Developer's-Guide-to-the-napari-hub
- Customizing your plugin's listing
- napari.org could have a page for using the napari plugin template
- running the template
- PROMPTS.md
- tour of the files
- editing the python files
- Link to your first plugin from the template
- napari/example-plugin
- test driven development
- great in theory
- bad in practicality
- *unless* someone is
-

### Action Items

Tim: what percent of plugins are maintained? marker for maintenance for the hub
- plan for the plugin
- what it takes to get a plugin into the org
- list of people that would shepherd the org
- what would the process look like to take over

## Wednesday 2025/11/26

Attendees: Guillaume, Carolyn Brokowski, Tim

### Agenda

- Tim's plugin upgrades -- what went well?
- Mega monolith: [napari-ndev](https://github.com/ndev-kit/napari-ndev)
- Organically grown, yucky pyproject https://github.com/ndev-kit/napari-ndev/blob/2290166fa20b903560f1323766c75600acce0c3e/pyproject.toml
- https://github.com/ndev-kit/ndevio
- importance of chron jobs - if there was one I would have known things were broken
- discuss the value of pre-commit hooks
- code assistants were incredibly valuable to understand CI failures
- https://github.com/ndev-kit/napari-ndev/pull/194
- numpy 2 changes
- (will add context later)
- tox is still confusing -- why don't we just have a simpler CI?
- there are redundancies with CI
- is the only importance of tox the environment variables?
- can do env variables with pixi
- pyproject.toml - Guillaume -- what are all the sections for?
- need an explanation for each section
- slim down pyproject
- dont even necessarily want ruff or black
- maybe try to find the simple vs advanced copier template that lives somewhere by talley'
- guide on how to upgrade would be useful, and what the common issues are
- guide to pinning dependences
- why separate plugin into multiple libraries?
- Guillaume has had some issues ripping things out, but eventually still have to test/pin
- guide on how to organize development projects
- Guillaume would be happy to help with trainings or videos
- beginner vs advanced
- docs... where to put it?
- Guillaume uses jupyter book
- Tim: fix tutorial resources links https://github.com/ndev-kit/resources/tree/main/image_archives
- Carolyn: use NIH osteoarthritis data for making an algorithm to understand if something has a bone lesion type thing

## Thursday/Friday 2025/11/20-21 (Pacific)

Attendees: James Ryan, Tim Monko, Draga Doncila Pop

### Agenda:

- Updating napari-lattice
- we can use Jame's work in updating this plugin to identify pathways for plugin developers to update older plugins
- setuptools_scm
- npe1 -> npe2. how to know if its npe2?
- look for a napari entry point in setup.cfg / pyproject.
- James tries to give it a minute to understand `napari.yaml`
- `napari.yaml` manifest
- command/id field are split - which is not intuitive
- Could commands have multiple contributions or no contributions?
- EDAM-ontology: an old way for people to identify what their plugin is used for?
- some hierarchy, and was REALLY complicated
- https://github.com/chanzuckerberg/napari-hub/wiki/Backend-%E2%80%90-Categories
- We *should* add domain categories <- try to care for bikeshedding
- https://github.com/chanzuckerberg/napari-hub/discussions
- version schema for the manifest (things like the new reader configs will require bumping)
- Composable vs standalone contribution
- need to make a default -> could be (unspecified, light dependencies, heavy dependencies) and (unspecified, standalone, composable)
- Single widget based plugins (ie. standalones) vs multi-widget (composable)
- napari-skimage provides composable toolbox style. we need good examples
- (missing key plugin types)
- Can we take advantage of tools like `uv --dry-run` to check for environment solves
- In particular, we can check against napari. we could do this on npe2api because its linear

### Action Items

- Tim: Start developing automated tooling
- James: Finish NAP-6 menu Contribution

## Wednesday 2025/11/12 (Atlantic)

Attendees: Jacopo Abramo, Tim Monko, Guillaume Witz, Brian Northan

### Agenda:

- Catch up with the crew
- Jacopo talks about the "synchrotron" world, which works on beam-lines and particle accelerators -- they have no commercial packages, instead using software engineers
- Bluesky was originally published in a niche synchtronon journal -- and Jacopo was lucky to find it through an user opening an issue on ImSwitch that mentioned Bluesky
- Bluesky core developer Daniel Allen made a spoiler of a use case of [tiled](https://github.com/bluesky/tiled) in conjunction with napari
- Bluesky was marketed as an a la carte solution, as each package is meant to be used standalone (but most of the time they're all used together):
- Bluesky: contains the run engine and provides `typing.Protocol` classes that define the basic interfaces needed for a device to talk with it;
- event-model: a representation of single events created by the actions of the run engine as python dictionaries, not attached to any kind of data format but meant to be consumed by, i.e.: HDF5, zarr, TIFF, ...
- tiled: client-server application for abstracting remote data access
- ophyd -- abstraction layers for the mostly known used control tools (EPICS and TANGO), but the difference here is that there is no workstation attached to the device (like is often the case for a microscope)
- each beamline gets its on repository for defining its own controls, so they are maintained separately
- a much more distributed approach; each beamline uses ophyd(sync/async) to describe their beamlines without touching the main core
- Guillaume was at OME-NGFF meeting
- Zarr NGFF is the future along
- https://ngff.openmicroscopy.org/
- a system of proposals like NAPs
- there are presently python packages for this
- people mostly showed off visualization with neuroglancer, partly because 3D large volume is not ready in napari
- Discussion about little composable widgets (which is generally the recommendation in documentation and stuff) vs bigger self-contained toolboxes (which is where the community has headed)
- Jacopo: people are often trying to replicate a Fiji-like experience for their specific use-case
- napari could provide more support for how to build these big packages
- napari could do better documentation on how to separate the view side (widget) from the functional stuff. so everything gets dumped into a single class.
- Guillaume: notes that the references say to separate the computational part from the widget part, but as a beginner this is very difficult
- Jacopo: napari doesn't document this itself
- Should we really be first-recommending @magicgui ?
- Guillaume, finds it easier to explain a Qt-based approach to explain the events, connections, etc
- Perhaps we need to clarify more explicitly the strengths of magicgui
- Brian suggests we pick the brain of Curtis Reuden for lessons learned from ImageJ2. if wrote a plugin it could work in both KNIME and ImageJ2 so it helped authors separate computation from visualization
- magic in software is dangerous
- One way we can reinforce this separate is to really show how to use the computation as API *and* identically in a widget
- Guided transition document (a "user story") about how to build up features, show it with magicgui where it gets really messy. then, we show how to properly separate computation from
- Jacopo really wants us to emphasize MVP/MVC
- Guillaume circles back to composable vs self-contained plugins.
- what would be nice is if we separated tools from toolboxes in terms of curation
- tools vs toolbox
- Jacopo: napari should be a toolbox, but right now its a tool
- declarative in Bluesky is helpful <- Jacopo thinks
- generalized vs domain-specific
- standardized inputs and outputs of functions
- Guillaume brings up nextflow https://nextflow.io/docs/latest/index.html /nf-core. this is for heavy duty workflows, maybe a bit advanced. People at the Crick were working on transitioning from napari pipelines to nextflow workflows to get things to work on HPCs. this is another one of those barriers between being a biologist and a comp developer
- This could be valuable in helping plugins be useful in the longer term
- We need a usecase for the transition to a nextflow workflow
- Brian discusses how to get things interoperable is often personal. This maybe moves us towards pixi, and this could be a way to get things to work together
- Take advantage of the lock systems to create reproducibility environments and for us to build documents
- Classifiers should identify the
- Perhaps there are Trove classifiers for this already?
- otherwise we can add to napari.yaml
- Guillaume, not pushing as far as devbio-napari, finds a set of plugins that work together. Imagines instead smaller bundles of plugins

## Wednesday 2025/10/15 (Atlantic)

Attendees: Jacopo Abramo, Tim Monko, Guillaume Witz, Brian Northan, Gaelle Letort, Grzegorz Bokota

### Agenda:

- Introductions
- Tim - napari-ndev https://github.com/ndev-kit/napari-ndev
- Jacopo Abramo - finishing up computational / physics phd thesis
- napari-live-recording (from czi grant) https://github.com/jacopoabramo/napari-live-recording
- now a new project with a plugin ecosystem https://github.com/redsun-acquisition
- Guillaume - physics and experimental biology -- first programming in matlab, then switching to python as deep learning approached
- supports users in a core, and builds both bespoke and general plugins
- https://github.com/guiwitz/napari-skimage
- Brian - does contract work
- interested in how to compare deep learning frameworks
- building plugins for this purpose, especially for ndimensional deep learning
- Gaelle - facility engineer at institute pasteur, sometimes fiji and sometimes napari
- knowing that users are struggling to install plugins -- too complex at this stage for biologist
- Grzegorz - core team member
- partseg still in maintenance mode https://partseg.github.io/
- Overview (Tim)
- How should projects be prioritized?
- Centralizing community resources (time, effort, stories)
- Community plugin review
- Template updates + model plugin
- Documentation and tutorials
- Improvements to npe2 and other plugin infrastracture

### Feedback

- Jacopo supports PyOpenSci
- Jacopo says an issue is there is no standarized way to write plugins -- i.e. "how to write code correctly"
- https://learn.scientific-python.org/development/ Covers the other side of things
- Jacopo suggest maybe a repo-review bot or something on Github, and likes
- Better documentation of how to use Github and stuff -- the real basics
- Jacopo suggests live reviews, like a zoom call, with emphasis on ability to make it private
- Even the tooling presents a barrier for scientists
- Jacopo would do review
- Grzegorz says there is motivation that is a barrier on "why would I want to learn all these tools"
- Persons will have difficulty wanting to continue what they learned
- How many things are a one-and-done deal? this is the ideal thing for us to have setup
- But the tooling/testing/git part is what requires maintenance over time, the "daily tools" are hard to learn
- Guillaume echos the difficulty of learning tooling and says to not count on standardization
- Guillaume - If there is a community of peope that have more of a "permanent position" or "service position" this would be great, and would be
- Guillaume - Having a centralized place on where people want help, whether its maintained or not, etc
- Guillaume - the bundle is great -- but having a list of plugins that are known to work with the bundle would be great. (like for example when packages pin Qt5)
- Gaelle - advertise the bundle better!!! and how to install old bundles
- Grzegorz - quality checks on compile / constraints . We can use npe2api for these checks
- Tim - should we introduce a "maintainer partner" that people could invite.
- Jacopo - says this is beyond where effort should be placed
- Grzegorz - problem of people leaving academia and such, and of course it can be a fork, but this dilutes the ecosystem.
- generally unsure how to resolve this
- potentially a paid service for long-term maintenance?
- Grzegorz - can people "donate" plugins to the community, and someone could pick it up if they want
- This idea got shared smiles and thumbs up
- Guillaume - case by case thing, makes this challenging to approach
- Guillaume brings up that there is interest in "picking back up" old plugins and upgrading them in an afternoon to work
- Guillaume - how is the bundle madE? can I have tools to do this myself?
- Grzegorz says a main problem is how to sign the executable
- https://napari.zulipchat.com/#narrow/channel/212875-general/topic/pixi.2C.20conda-forge.2C.20and.20desktop.20apps/with/544941972
- Jacopo - there should be a napari-plugin organization where people can be given a role, and then that role can be added to other people's repos -- something like "plugin contributor" and "plugin-maintainer"
- perhaps this would help stripping down napari towards napari-lite
- also need to think about a pypi organization for this
- Jacopo links https://pymodaq.cnrs.fr/en/latest/tutorials/git_tutorial.html for documentation for how to use github and other tools
- and this for more detail https://learngitbranching.js.org/?locale=it_IT
- Grzegorz - how to help people with motivation
- GitHub GUI
- Maybe Github actions that would ping people for napari API changes that are relevant
- napari generally doesn't break things for plugin devs, especially plugin API
- but napari could still reveal new features better (though there has been improvement recently!)

### Biggest challenges

- Jacopo packaging in Github actions
- Gaelle getting GPU tools working (tensorflow especially on Windows depending on drivers) - Stardist
- Tim suggests Brian write up his thoughts on getting these different DL/GPU
- Guillaume - again resonates with DL issues -- is making containers to try to resolve this
- A difficult to install is deeplabcut
- How to report errors, how to ask questions, how to use LLMs for fixing errors
- Grzegorz - how to make a Github account even,
- How can we approach LLMs and its novel use, especially for beginners
- Readers/writers and their dependency hell is an issue. napari-aicsimageio is an example of both being amazing, and trying to do too much at once
- We need to have more multi-package repos / projects, rather than mono projects (ApacheAirFlow is an example)
- This is not well supported / well documented in python
- IO is such a problem, but FIJI does this better still

### Next steps
- PLugin review :thumbs-up:
- Documentation for getting started from the ground up
- Automated quality check tooling
- We need to have or develop best practices
- feedback -> blog -> NAP
- NAP - plugin donation program
- NAP - automated and human review

## Thursday 2025/10/09 (Pacific)

Attendees: Tim, Draga, James R., Juan, Pradeep

### Agenda:

1. Introductions
3. Overview (Tim) - including any initial data collected
4. How should projects be prioritized?
- Centralizing community resources (time, effort, stories)
- Community plugin review
- Template updates + model plugin
- Documentation and tutorials
- Improvements to npe2 and other plugin infrastracture

### Notes

1. Introductions
- James R. - will be working with Juan on migrating napari-lattice to latest napari version
- Pradeep - bioimage analyst at WEHI. Microscopy core (10-15 microscopes) + an image analysis core facility.
- facility has lattice-lightsheet microscope, Zeiss instrument, .czi files
- napari-lattice came out of this work. Analysis plugin
- CLI component for batch processing on HPC
- "freed us up from using the zeiss software"
- want to avoid data duplication
- dependency problems with aicsimageio, would love to migrate to bioio
- no bioio reader?
- https://github.com/ndev-kit/napari-ndev - Tim's plugin
- started with aicsimageio in 2023
- immediate dependency problems
- switched to bioio pretty much immediately
- not on conda atm, but neither is napari-lattice
- https://github.com/ndev-kit/napari-ndev/blob/main/src/napari_ndev/nimage.py
- https://github.com/ndev-kit/ndevio
- currently on 0.5 but would really love to get to use latest napari
2. Pradeep - is there a "workflow" sort of system to work from end to end, or plugin-to-plugin workflows
* snakemake (native python) workflows, nextflow has been seeing adoption in bioimaging space
* workflows are on the *napari* roadmap, but we don't want to reinvent the wheel

7. Plugin movement on the napari side
* Progress on the manifest and NAP-6
* 0.7 allows us to make a new statement
8. Analytics of plugins
* Displaying aggregate analytics is always ok
* something like "270 out of 550 plugins have"
* But for individual plugin pages, there has been (understandably) hesistancy in showing metrics
* Draga does not think individual analytics should be opt-in, because if we believe that it is useful to see, then we show it
* napari-hub used to show downloads, but we don't have the logic for all the complex filtering
* previously we filtered out bot downloads and the night of an API scrape
* if we do analytics, we need to *show* the code and *document* the analytical methods
* providing an API to query metrics for plugin authors, and it could be on the individual plugin pages
* Draga emailed hub team to ask for the original code for filtering download numbers, and to see if we could do a quick audit of the feature differences.
9. What kind of documentation/tooling could help for maintenance
- updates to the template that can be merged into existing plugins?
- plugin review system that shows what dev can do to make plugin more maintainable? make it easier for others to contribute?
- Pradeep: worked on napari-lattice until last year and realised we needed RSE support. Want something sustainable longer term. Had some funds to allocate to an RSE, they helped with the plugin. Recent updates to napari, not well versed to comments. Templates/plugin review system would be very useful. Talking to people is probably the best way because documentation is not interactive.
- https://www.pyopensci.org/ - new initiative that can offer peer review for open source software. Give guidance on python packaging and learning materials.
- you can submit your package and do a quality check
- we can add our own napari-specific part of it that checks best practices, CI updates
- get feedback from a real human being on your plugin
- Pradeep: npe1 used to have a lot of "hacky" stuff to get stuff done, with npe2 you don't need to do a lot of that anymore, but guidance on updates would be very helpful