What should file opening behavior be when multiple plugins are available?

[DragaDoncila]

Pre-npe2 file opening behavior with plugins proceeded in a cascading manner, trying plugins until one was successful, or all failed. Users had control over this behavior by way of the plugin hook sorter in preferences - they could disable and reorder reader plugins to ensure their plugin was tried first/certain plugins weren't tried at all/etc.

However, this cascading behavior was an artifact of using pluggy as the base for our napari-plugin-engine, and is not being replicated in npe2. To initially address the issue that users would not be able to select their plugin for reading a particular file, we introduced the reader dialog in #3799, which popped up if and only if multiple plugins were available for reading a file. The dialog also allows for saving preferences for file extensions, so that you're not asked about the same file over and over. We made no decisions about saving preferences for folders.

#3799 only affected GUI users however, as users calling viewer.open at the command line could pass in their desired plugin and therefore had some semblance of control. This has (of course) led to inconsistent behavior for users, as evidenced in this zulip thread where saved preferences were not respected using viewer.open, and in this thread where File -> Open wasn't popping up the file dialog (or respecting preferences for that matter).

To Reproduce

A simple example of these inconsistencies:

1. Install napari-tifffile
2. Drag a tif into the viewer - the reader dialog will pop up. Select builtins and leave the checkbox ticked.
3. Close the viewer then open the same file from a script or interactive console using viewer.open()
4. File is opened with napari-tifffile despite saved preference for builtins

Expected behavior

We have not yet, as a group, defined what we want expected behavior to be when users try to open a file and multiple plugins are available for reading, and whether this is different from the command line as opposed to the viewer.

Considerations:

• Do we want the behavior to differ between the viewer and the command line?
• Does the answer to the above change when we're talking about the interactive console in the viewer?
• Are folders different from files, since we're not able to save preferences?
• Do we want to replicate some of the "cascading" behavior from napari-plugin-engine to avoid throwing errors when plugins are available?
• Do we want users to be able to add some sort of preference for what happens when multiple readers are available?

Example

An example PR for how we could address this inconsistency is #4102 which introduces a select_reader_helper parameter to viewer.open. To summarize this discussion, it's "what do you think should happen after this line?". However, it's unlikely we'll know what the code should look like until we define what we want the behavior to be.

[tlambert03]

trying to summarize what I think was just said in meeting:

• viewer.open(), when called via code (regardless whether it's in the builtin console, ipython, script, etc)
  • (note, each of these assume plugins=None, otherwise the plugin must match)
  • if no plugins available: raise
  • if one plugin available: use it
  • if more than one plugin available:
    • if builtins provides a reader for the file, use it. question here: should we warn that others were available?
    • otherwise just raise an exception listing the available plugins.
• anything in the gui... including drag/drop, File -> Open, or napari some_file.ext from the cli
  • basically the current behavior: no plugins = raise, 1 plugin = use it (but don't store preference), 2 plugins = dialog

not discussed in the meeting, but i think i'd propose: viewer.open() probably shouldn't implicitly save and any file association preferences. We should have a different explicit API for that

[andy-sweet]

save and file association preferences

Did you mean save and read file association preferences?

[tlambert03]

oops, sorry. meant "save any" (will correct)

[DragaDoncila]

question here: should we warn that others were available?

I think yes we should, though I can see that being super annoying so maybe we want to offer the option of silencing it? Or we just warn once and tell users to go to preferences to opt out of the "builtins by default" preference?

not discussed in the meeting, but i think i'd propose: viewer.open() probably shouldn't implicitly save and any file association preferences. We should have a different explicit API for that

1000% agreed.

There's just two other considerations I think:

1. If a preference exists, that preference should be used, so the workflow is more:

• viewer.open(), when called via code (regardless whether it's in the builtin console, ipython, script, etc)
  • (note, each of these assume plugins=None, otherwise the plugin must match)
  • if no plugins available: raise
  • if preference is saved: use it
  • if one plugin available: use it
  • if more than one plugin available:
    • if builtins provides a reader for the file, use it. question here: should we warn that others were available?
    • otherwise just raise an exception listing the available plugins.

Now, let's say we have a preference saved and it doesn't work (can't find it or it fails) - do we then proceed through checking if there's just one plugin (that wasn't the preferred plugin) left or if builtins is available and use that, or do we reraise whatever the preferred plugin error was? In the GUI, we reopen the dialog in this instance (even if just one plugin is available). My preference is that in the console, we simply reraise.

2. We were pretty happy in the meeting with "if multiple plugins available and builtins provides a reader for the file, use it.". That is not the current GUI behaviour - we would just open the dialog here. Do we want to update this to use builtins if available? Or are we happy for this to be different behaviour in the console vs the GUI?

[andy-sweet]

This is a little redundant with @tlambert03's response, but here are my answers.

• Do we want the behavior to differ between the viewer and the command line?

Yes. The viewer should display the dialog in the ambiguous case. The command line should not and it should not require command line input either.

• Does the answer to the above change when we're talking about the interactive console in the viewer?

No. Because I wouldn't expect the behavior of a function call to change based on where it's being called from.

• Are folders different from files, since we're not able to save preferences?

I don't know. In principle, folders/directories can have an extension (in that their name can have a . in), but typically don't. I assume that npe2 wouldn't support that though (i.e. it treats directories as a separate/special case)?

• Do we want to replicate some of the "cascading" behavior from napari-plugin-engine to avoid throwing errors when plugins are available?

I think my favorite option right now is if there's exactly one plugin then use it, otherwise (if there are None or multiple) raise, just because it's fairly simple. But I wouldn't block some sensible default and warn option either.

• Do we want users to be able to add some sort of preference for what happens when multiple readers are available?

Probably not, just because it makes the logic harder to understand.

---

I also think there's a slightly bigger question lurking here. Does Settings only store state that is relevant in the viewer/GUI/app? Or should the values it stores affect the behavior of napari public function calls (including open, but others too) that I would expect to use without the GUI?

I don't have an answer, but I lean towards making Settings state that is associated with the viewer/app, and plain public API function calls should not depend on that state.

A related question is if public API function calls should depend on the Python environment. For example, if a plugin package is installed, should the behavior of open depend on that? I think the answer to that is almost definitely yes. But maybe it also matters if a plugin has been registered with napari/npe2? Again it would be useful to clarify who owns that state.

[DragaDoncila]

I don't know. In principle, folders/directories can have an extension (in that their name can have a . in), but typically don't. I assume that npe2 wouldn't support that though (i.e. it treats directories as a separate/special case)?

Actually, directories with extensions e.g. .zarr are put in the extension bucket and therefore passed to napari readers as though they weren't directories at all I think - @tlambert03 or @nclack can confirm?

I don't have an answer, but I lean towards making Settings state that is associated with the viewer/app, and plain public API function calls should not depend on that state.

I honestly am struggling to think of API calls that a user would make that might change as a result of settings but don't have any connection to the viewer? I feel like I need an example to even start thinking about this question

[andy-sweet]

I honestly am struggling to think of API calls that a user would make that might change as a result of settings but don't have any connection to the viewer? I feel like I need an example to even start thinking about this question

One specific example I was thinking of is when a preferred plugin has previously been saved for a particular file extension. Is that preference considered part of settings state? I was assuming it is, but I might be confusing different things (i.e. preferences vs. settings).

If so, the question is should the behavior of Viewer.open should depend on that state? From the conversation so far, it sounds like the answer is yes because when plugins=None, we will read that state to determine the behavior of open. I'm also OK with that as open is a method of Viewer and not just a plain function in the napari module, so it's natural for it to depend on more state than it receives as parameters.

[andy-sweet]

One other point that I missed when first thinking about this, but is obvious in retrospect, is that open is a method of Viewer (more specifically ViewerModel), so that makes it more natural for its behavior to depend on other state related to the viewer. I.e. it is not a plain function like napari.open.