reconsider returning a list of strings in writer plugins

[tlambert03]

complete side note here... @nclack, maybe we should reconsider the "merit" of requiring them to return a list of strings. Do we do anything with it? could we instead check os.stat of the path to check if anything happened? or, is there good reason to require them to return a list of paths (e.g. perhaps with remote paths where we can't evaluate before/after)

Originally posted by @tlambert03 in napari/cookiecutter-napari-plugin#130 (comment)

[tlambert03]

from @nclack

totally agree. Returning the list of strings is awkward. We don't really do anything with the info and it would be more natural for people to rely on exceptions.

os.stat as a check is an idea, but it has some cost and doesn't really do anything that a properly handled write API doesn't do.

[nclack]

this would be a schema version bump?

[tlambert03]

hmm... a good question. it doesn't change the schema does it, but it does change the api expected of the plugin. This was that kinda amorphous "napari plugin API" version that we've discussed before. Did we decide just to use schema_version for that? Or was schema_version reserved for how we're supposed to interpret/parse the manifest itself

[nclack]

I think we should use it for both.

Here it might mean the implementation of npe2.io_utils._write calls writer.exec() in a different way depending on the schema version. So npe2 unifies the varying calling behaviors so napari can just think about the new one (as far as npe2 is concerned).

Implementing the change might look like:

1. defining how we want the failure behavior to look on the napari side
2. adapting the current behavior on the npe2 side by using the schema version to adapt the handling of the current behavior to the new one
3. implement the napari side