Relax napari version pin

[C-Achard]

Motivation

Now that the newest major release at the time of writing (0.3.1.0) is live, it would be useful to relax the napari version pin to allow users to install the most up-to-date napari version, and keep development closer to napari releases.

Updated version of #201

Changes

• compat layer:
  • Broaden compatibility of guess_continuous
  • Broaden compatibility of Points copy/paste interaction

Timing

Confirming that the current refactored version works well on napari==0.6.6 should come first, and once we feel confident the plugin is in a proper stable state, we should consider making a minor release with only the version bmp (and not as part of shipping broader fixes/refactors) to avoid compounding effects.

Viability

A few notes on expected behavior and safety:

• DLC GUI auto-update will pull the latest napari version (as it always uses --upgrade)
• The newly added compat layer should help mitigate breaking API changes
• The debug log utility system should help track which version people use

Alternatives

Overall, since the plugin makes fairly deep use of the napari API, especially around Qt events, Points layers controls UI, and layer wiring, a preferable alternative may be to periodically check the newest napari version, validate first, and then bump the version.

A middle ground would also be to set an upper bound on the major release, e.g. since 0.7.0 seems compatible with or v0.3.0.0, we could pin to >0.6.6,<0.8 to retain fixes but avoid potential breaking changes, such as _qt_window access deprecation.

[Copilot]

Pull request overview

This PR relaxes the hard napari dependency pin and extends the project’s napari compatibility shims so the plugin can run across a broader range of napari versions without breaking on API changes.

Changes:

• Relax napari==0.6.6 to napari>=0.6.6 in packaging metadata.
• Update the compat patch for guess_continuous to support multiple napari module locations and call signatures.
• Adjust the Points-layer paste compat handler to use selected_data (newer napari API) with error-logging.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/napari_deeplabcut/napari_compat/points_layer.py	Updates paste-selection logic for newer napari versions (but currently introduces selection regressions / a no-op line).
src/napari_deeplabcut/napari_compat/color.py	Broadens guess_continuous monkeypatch compatibility across napari versions/modules.
pyproject.toml	Relaxes the napari dependency pin to allow newer napari versions.

Comments suppressed due to low confidence (2)

src/napari_deeplabcut/napari_compat/points_layer.py:364

• This line is a no-op expression and likely a leftover from npoints = len(layer_self._view_data). As written it computes the length and discards it, and will also trigger unused-expression linting. If npoints is still needed for selection bookkeeping later in this function, assign it explicitly here.

            cmap_source = cmap_source()

src/napari_deeplabcut/napari_compat/points_layer.py:390

• The paste handler no longer updates the private selection state (_selected_view/_selected_data). Older napari versions and the compat unit tests in this repo expect these to be updated after paste; relying only on selected_data will silently skip selection updates when that public API is not available.

    ----------
    add_impl
        Callable like keypoints._add bound to store.
    schedule_recolor
        Callable(layer) -> None.
    """
    try:

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[C-Achard]

@deruyter92 How long do you think we should wait before merging this ? I'm still concerned about stacking DLC 3.0 + napari-DLC tracking + a major napari version bump in terms of maintenance

[deruyter92]

We can always revert if unforeseen trouble is caused? How would you rate our test coverage now? functional/integration tests could pick any breaking changes relatively early, so we know when to set an upperbound.

[C-Achard]

We can always revert if unforeseen trouble is caused? How would you rate our test coverage now? functional/integration tests could pick any breaking changes relatively early, so we know when to set an upperbound.

Coverage on main is ~85%, when I bumped to 0.7 it did show some failures but not all, I tried to address that.
The e2e and compat layer tests should catch a good amount of core usability issues, hopefully