Use full plugin_name when finding chosen reader rather than startswith

[DragaDoncila]

Prior to this PR, the wrong plugin might be chosen when multiple compatible readers are available with similar names, and the user chose to use a plugin with a shorter name. As a concrete example, if a user chose explicitly to read a file with napari, but a plugin with a longer name that starts with napari was also compatible, e.g. napari-tifffile, the user's choice may have been ignored, depending on which plugin came up first in the comparison.

To avoid this, this PR changes the comparison from rdr.command.startswith to strict comparison on rdr.plugin_name. I've added a test that always passes in this branch, and only sometimes passes on main (😬) but I'm not sure if it's worth keeping it or if we are all just happy to accept the logic 🤷‍♀️

[codecov]

Codecov Report

Merging #297 (8707304) into main (3486638) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main      #297   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           37        37           
  Lines         2788      2788           
=========================================
  Hits          2788      2788           

Impacted Files	Coverage Δ
src/npe2/io_utils.py	100.00% <100.00%> (ø)

[jni]

That is... Pretty crazy. LOL

I can vaguely imagine the logic. Like, it's cool that git checkout works with only the first few digits of a hash... But in a world where most plugin names start with napari-, that's, um, not a good strategy! 😂

[DragaDoncila]

Pretty sure the napari tests failure is unrelated... it's a napari-svg saving test

[jni]

@DragaDoncila this seems like a genuine failure? I think?

https://github.com/napari/npe2/actions/runs/5285688739/jobs/9564414847?pr=297#step:6:241

ValueError: There is no registered plugin named 'svg'.
Names of plugins offering writers are: set()

[DragaDoncila]

@jni I don't think it's possible for it to be related to this change, but I will take a closer look - I've been surprised before 😂

[jni]

LOL Sorry, GH not updating. 😅 Um, yeah, there's been some issues with napari-svg recently but I don't know what the CI setup is/means here. I hope @tlambert03 or @Czaki might be able to comment on what the napari-tests job is supposed to catch and whether anything needs to be done here...

[jni]

The other failure is definitely unrelated. I saw a few toots about how to drop codecov yesterday so I expect it's a widespread thing. 😂

[DragaDoncila]

napari-tests runs all plugin related tests from napari's own suite to make sure changes in npe2 aren't breaking stuff on napari side. So we defs need to look into it, just don't think it's this specific change

[Czaki]

@jni I have described you a problem with napari-svg related test at the community meeting. The source uses the compression of strings instead of a comparison of versions.

The workaround is using a constraints file when installing napari. see #298.

We also need to add test for the latest released version of napari to avoid recent problems with npe2 0.7.0 and napari 0.4.17

[Czaki]

In the context of wrong plugin selection. In PartSeg I have 2 plugins to read tiff files. First read plain tiff, second read tiff if there is the additional file with suffix _mask.tiff. Napari randomizes which plugin contribution to use for this. Sometimes load with a mask, sometimes without.

[DragaDoncila]

Sounds grim @Czaki. If you can make a reproducible example or point me to how I can run the right workflow I'll happily look into it.

[Czaki]

As I think it is npe2 bug, and then I open the Issue here: #299

There is a movie showing the problem in this issue.