possibilities & rules for a plugin to dynamically update its manifest.

[tlambert03]

was just working with napari-aicsimageio, which can potentially support a huge amount of file extensions, but has its own plugin system that essentially determines what is and isn't available. Meaning a single static manifest is unlikely to accurately report what it can do at runtime. I know that @ctrueden has a similar challenge with pyimagej and napari, since the ops available will depend on the underlying fiji installation.

it would actually be rather easy for a plugin (or anyone really 😂) to modify that manifest at runtime:

from npe2 import plugin_manager

mf = plugin_manager.get_manifest('napari-aicsimageio')
mf.contributions.readers[0].filename_patterns = ...  # something new

however, since that's not an expected mode of interaction, the immediate consequence of that is undefined. (that is, it may not be reflected in the right places in napari unless it triggers a "re-index" ... and that may or may not happen depending on the contribution type).

So, this raises a couple thoughts:

1. Should we freeze manifest objects after instantiation? (maybe probably?)
2. Should we provide a tested mechanism to update them, as above? So that pyimagej can update its commands and aicsimageio can update its filename patterns? (this seems like a definite yes)
3. If so, should we attempt to restrict who can update a manifest? For example, we could do a simple stack inspection to determine if the request to modify the manifest is coming from a module in the package that we know "owns" that manifest... and reject it otherwise. Might be overkill, but given the monkey business we're starting to see, maybe not? 😂
4. what are the appropriate signals to emit when a manifest has been updated? (this kinda ties in to improvements on our internal contributions indexing strategy ... not a particularly hard question, but something we need to answer)

[tlambert03]

cc @nclack

[nclack]

2. Should we provide a tested mechanism to update them, as above?

Yes

3. If so, should we attempt to restrict who can update a manifest?

Sounds fine in principle - better to start restrictive. Some of the answer depends on how complex the solution is and I wonder if the stack inspection approach is really necessary. There are already expectations around not using private interfaces to do things. If we're doing some controlled access to manifests maybe it's enough to just make things difficult at the api level. 🤷

4. what are the appropriate signals to emit when a manifest has been updated?

This seems like the key thing. Naively, I like for folks who modify their manifest to declare something has changed. I'd like manifests to be immutable. Maybe someone can init a DynamicPlugin with an existing manifest, modify, and then register it. Registration would make it immutable again. The registration process might kick off all the necessary updates in the ui? I don't know. It's pretty interesting.