-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add specific error when reader plugin was chosen but failed #276
Conversation
Codecov Report
@@ Coverage Diff @@
## main #276 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 37 37
Lines 2813 2815 +2
=========================================
+ Hits 2813 2815 +2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
if we agree this should be the fix I'll fix the napari test also |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ValueError: There is no registered plugin named 'napari-ome-zarr'.
-> ValueError: Plugin napari-ome-zarr was selected to open ['./non-zarr-folder/'], but returned no data.
this is of course a million times better... and I have no issues with this PR, go for it.
... but I don't see why this PR would have that effect on the napari side? From what I can tell, it simply changes the message one would receive, but still raises a ValueError
? whereas in your example the full stack trace changed (and read_data_with_plugins
went from line 104 to line 77). Are you sure this PR was the only change? I would have definitely assumed that the bad "no plugin registered" problem needed to be fixed on the napari side (and which would be fixed most easily by getting rid of all the old npe1 cruft and just using this npe2 logic)
edit oops i see that it was a different place in read_data_with_plugins
that raised the exception... not a code change. but i still don't see why until i look at the code closer... wouldn't it be a ValueError from npe2 either way?
@tlambert03 yeah it's kinda insidious but this line catches the |
Also @tlambert03 how do I go about making the corresponding PR to fix napari tests? Do we leave this open and then I make the PR there? Or do we merge & release this and then make a PR bumping |
oh ffs 😂 I had a feeling it was going to be something like that... and I even have a vague feeling of having to use that hack for some reason here. sure, by all means, merge this and then kill that code in napari ASAP |
your call. since (as far as I can tell) the only thing failing is that napari is asserting a specific error string match, you might just soften that test on the napari side and simply assert a ValueError... but the order of merge operations doesn't seem super critical to me. (fine to merge this with failing napari tests for a few days for example) |
Yeah, this seemed like the smallest change that would do what we want, and it has the added effect of being a nicer error message here too. But agree, npe1 code needs to go |
I'm going to merge this. I think once we get #275 merged maybe we can do a release? |
since @DragaDoncila improved the error message on the npe2 side in napari/npe2#276 ... the npe2 test suite now fails when it runs napari tests due to an expectation of an outdated error message. This just relaxes that error message match so that tests can pass on npe2 again --------- Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com>
since @DragaDoncila improved the error message on the npe2 side in napari/npe2#276 ... the npe2 test suite now fails when it runs napari tests due to an expectation of an outdated error message. This just relaxes that error message match so that tests can pass on npe2 again --------- Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com>
since @DragaDoncila improved the error message on the npe2 side in napari/npe2#276 ... the npe2 test suite now fails when it runs napari tests due to an expectation of an outdated error message. This just relaxes that error message match so that tests can pass on npe2 again --------- Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com>
since @DragaDoncila improved the error message on the npe2 side in napari/npe2#276 ... the npe2 test suite now fails when it runs napari tests due to an expectation of an outdated error message. This just relaxes that error message match so that tests can pass on npe2 again --------- Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com>
since @DragaDoncila improved the error message on the npe2 side in napari/npe2#276 ... the npe2 test suite now fails when it runs napari tests due to an expectation of an outdated error message. This just relaxes that error message match so that tests can pass on npe2 again --------- Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com>
since @DragaDoncila improved the error message on the npe2 side in napari/npe2#276 ... the npe2 test suite now fails when it runs napari tests due to an expectation of an outdated error message. This just relaxes that error message match so that tests can pass on npe2 again --------- Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com>
since @DragaDoncila improved the error message on the npe2 side in napari/npe2#276 ... the npe2 test suite now fails when it runs napari tests due to an expectation of an outdated error message. This just relaxes that error message match so that tests can pass on npe2 again --------- Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com>
Currently we raise the same error in
read
when no layer data is returned by any of the tried readers, regardless of whether a plugin name was given or not. This PR updates the error message to be specific when aplugin_name
is passed.This has the added benefit of fixing this issue over in
napari-ome-zarr
(which is actually a reincarnation of what napari #4026 was trying to solve) by ensuring the error is re-raised over on thenapari
side.I thought about whether a fix should go in
napari
instead, but I think this is the right place to fix this. Over innapari
we would have to track somehow whether a plugin was tried or not so that we could know whether to continue withnpe1
plugins. But I think if the user chose a plugin, and it failed,npe2
should alert to that, rather than shuffling it under a general "there were no readers that could read this" error.Before this PR, running e.g.
napari --plugin napari-ome-zarr ./non-zarr-folder/
gave:Whereas now it gives: