Add npe1_shim field to schema

[tlambert03]

This adds a new top level npe1_shim field to the schema, which will make it possible to determine whether a serialized manifest represents a shimmed npe1 plugin or not.

This also makes sure that all shim manifests have their contributions loaded before serialization

cc @DragaDoncila

[codecov]

Codecov Report

Merging #182 (032cd9e) into main (772f49f) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main      #182   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           27        27           
  Lines         1789      1794    +5     
=========================================
+ Hits          1789      1794    +5     

Impacted Files	Coverage Δ
npe2/manifest/_npe1_adapter.py	100.00% <100.00%> (ø)
npe2/manifest/schema.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 772f49f...032cd9e. Read the comment docs.

[DragaDoncila]

This looks great to me, thank you @tlambert03 🙏 . Two questions:

• Could we use this in the plugin dialog on the napari side to avoid npev = 'shim' if 'npe1' in type(manifest).__name__.lower() else 2? I know with napari #4692 it'll matter less but it may still be useful for users to know whether a plugin is native npe2 or not.
• Now that we load contributions before serializing, does that mean we can get rid of the call to index_npe1_adapters on the napari hub side which we were using to force contribution discovery, even though we're exporting to json? I assume _serialized_data gets called when writing to any filetype?

[tlambert03]

Could we use this in the plugin dialog on the napari side to avoid npev = 'shim' if 'npe1' in

yes!

does that mean we can get rid of the call to index_npe1_adapters on the napari hub side which we were using to force contribution discovery, even though we're exporting to json

yes!

[tlambert03]

does that mean we can get rid of the call to index_npe1_adapters on the napari hub side which we were using to force contribution discovery, even though we're exporting to json

actually, even better @DragaDoncila ... you should just be able to do this now from the cli

npe2 parse napari-compressed-labels-io > napari.yaml

name: napari-compressed-labels-io
schema_version: 0.1.0
contributions:
  commands:
  - id: napari-compressed-labels-io.get_reader
    title: Get Reader
    python_name: napari_compressed_labels_io._reader:get_label_image_stack
  - id: napari-compressed-labels-io.get_reader
    title: Get Reader
    python_name: napari_compressed_labels_io._reader:get_zarr_labels
  - id: napari-compressed-labels-io.write_labels
    title: Write Labels
    python_name: napari_compressed_labels_io._writer:labels_to_zarr
  readers:
  - command: napari-compressed-labels-io.get_reader
    filename_patterns:
    - '*'
    accepts_directories: true
  - command: napari-compressed-labels-io.get_reader
    filename_patterns:
    - '*.zarr'
    accepts_directories: true
  writers:
  - command: napari-compressed-labels-io.write_labels
    layer_types:
    - labels
    filename_extensions: []
    display_name: labels
npe1_shim: true

I'll add something to allow export to json