Add minimal napari requirement for the plugin to be discovered #55
Conversation
Codecov Report
@@ Coverage Diff @@
## main #55 +/- ##
==========================================
- Coverage 92.59% 92.43% -0.17%
==========================================
Files 3 3
Lines 189 185 -4
==========================================
- Hits 175 171 -4
Misses 14 14
Continue to review full report at Codecov.
|
|
This is now ready for review. The Python 3.7 tests started failing with an error similar to napari/napari#4747 and I realise that |
|
Not related to this PR, I just started getting this error using this plugin... stack tracewith: From the I pip uninstalled This actually fixed the problem! Not sure I see any changes here that explain why this works now, but 🤷 . Changes look good and build is green: 👍 |
|
Strange that I don't see
|
|
Hmmm - when I try opening a Plate I get... |
|
I do see |
|
Thanks @will-moore, you're right and this matches what I had found in #42 (comment). Specifically testing with the latest napari release, |
so I don't see an immediate issue with the manifest (upgraded in #42) itself. |
|
@sbesson Any idea what version of |
|
Ah, it seems that updating napari to latest fixed this issue for me... |
|
I can load plates now, but still not Wells (either with main branch or with ome/ome-zarr-py#209). |
|
Tested a few napari versions ( I never get the plugin to be recognized. Recent versions of napari simply do not list it and older versions list is in My attempts at validating the plugin after the upgrade to the new plugin engine do not reveal any immediate issues @jni @DragaDoncila (and other napari developers): any suggestion on how to increase the logging verbosity and understand what causes this regression? or any obvious candidate for the root of this issue? |
|
Ok so @sbesson I've tracked down a few things:
name: napari-ome-zarr
schema_version: 0.1.0
contributions:
commands:
- id: napari-ome-zarr.get_reader
title: Get Reader
python_name: napari_ome_zarr._reader:napari_get_reader
readers:
- command: napari-ome-zarr.get_reader
filename_patterns:
- "*.zarr"
- "https://*.zarr/"
accepts_directories: true
I hope this helps, but please don't hesitate to ping me if there's any further issues! |
|
Many thanks for detailed trackdown @DragaDoncila. Somehow I had missed the failing command were using trailing slash. @will-moore I have pushed an extra commit to support |
tox.ini
Outdated
| @@ -1,12 +1,13 @@ | |||
| # For more information about tox, see https://tox.readthedocs.io/en/latest/ | |||
| [tox] | |||
| envlist = py{37,38,39}-{linux,macos,windows} | |||
| envlist = py{37,38,39,310}-{linux,macos,windows} | |||
|
6121d50 should drop Python 3.7. On minor vs patch no strong opinion either way but my understanding is that the migration to |
|
Ah, so the original 0.5 bump essentially had this requirement it just wasn't documented. Check. |
Just confirmed my statement was correct with a test environment using napari 0.4.12 with napari-ome-zarr 0.5.0 |
|
So, this means that for HCS Wells, e.g. E.g. as in ome/ome-zarr-py#209 |
|
If you want to support opening subgroups, you could always do |
See #42 (comment)
While this plugin does not directly consume
napariAPIs, the plugin engine mechanism requires a minimal version of upstreamnapari. This proposes to use the standard Python packaging markup to capture this minimal requirement.Proposed tag:
0.5.1