TypeError: unhashable type: 'Color' during Qt resource compilation

[alisterburt]

🐛 Bug

Came across a bug after a fresh install of napari today, pyqt was installed through conda, napari from pip

Traceback (most recent call last):
  File "/Users/alisterburt/programming/fourier-nerf/cif_to_mrc.py", line 28, in <module>
    viewer = napari.Viewer(ndisplay=3)
  File "/Users/alisterburt/mambaforge/envs/fourier-nerf/lib/python3.10/site-packages/napari/viewer.py", line 61, in __init__
    self._window = Window(self, show=show)
  File "/Users/alisterburt/mambaforge/envs/fourier-nerf/lib/python3.10/site-packages/napari/_qt/qt_main_window.py", line 414, in __init__
    get_app()
  File "/Users/alisterburt/mambaforge/envs/fourier-nerf/lib/python3.10/site-packages/napari/_qt/qt_event_loop.py", line 195, in get_app
    _register_napari_resources()
  File "/Users/alisterburt/mambaforge/envs/fourier-nerf/lib/python3.10/site-packages/napari/_qt/qt_resources/_icons.py", line 438, in _register_napari_resources
    resources = _compile_napari_resources(save_path=persist and save_path)
  File "/Users/alisterburt/mambaforge/envs/fourier-nerf/lib/python3.10/site-packages/napari/_qt/qt_resources/_icons.py", line 374, in _compile_napari_resources
    with _temporary_qrc_file(svgs, prefix='themes') as qrc:
  File "/Users/alisterburt/mambaforge/envs/fourier-nerf/lib/python3.10/contextlib.py", line 135, in __enter__
    return next(self.gen)
  File "/Users/alisterburt/mambaforge/envs/fourier-nerf/lib/python3.10/site-packages/napari/_qt/qt_resources/_icons.py", line 99, in _temporary_qrc_file
    for alias, xml in xmls:
  File "/Users/alisterburt/mambaforge/envs/fourier-nerf/lib/python3.10/site-packages/napari/_qt/qt_resources/_icons.py", line 169, in generate_colorized_svgs
    yield (alias, get_colorized_svg(path, color, op))
TypeError: unhashable type: 'Color'

To Reproduce

Steps to reproduce the behavior:

1. launch napari in this environment

Expected behavior

succesful napari launch

Environment

napari: 0.4.16
Platform: macOS-12.5-arm64-arm-64bit
System: MacOS 12.5
Python: 3.10.6 | packaged by conda-forge | (main, Aug 22 2022, 20:41:22) [Clang 13.0.1 ]
Qt: 5.15.4
PyQt5: 5.15.7
NumPy: 1.23.2
SciPy: 1.9.1
Dask: 2022.8.1
VisPy: 0.10.0

OpenGL:
  - GL version:  2.1 Metal - 76.3
  - MAX_TEXTURE_SIZE: 16384

Screens:
  - screen 1: resolution 1512x982, scale 2.0

Plugins:
  - console: 0.0.4
  - mrcfile-reader: 0.1.3
  - napari-svg: 0.1.6
  - scikit-image: 0.4.16

Additional context

I have other working environments on this machine with 0.4.16 so the problem is likely somewhere slightly upstream...

[psobolewskiPhD]

I can confirm this on my M1 arm64 env, in python 3.9 arm64 env.
(pyqt from mamba, napari from pip)
But napari from conda-forge works...
Edit: via mamba, so getting 0.4.16

[alisterburt]

also brand new for you?

[psobolewskiPhD]

Yea. I make napari envs a lot too, but usually via mamba.

[Czaki]

@alisterburt please check if downgrade pydantic to 1.9.2 form 1.10.0 will solve your problem. The 1.10.0 was released 6 hour ago and create same problem for me on ubuntu. It looks like deprecation in a new release.

[alisterburt]

thank you @Czaki, that solves the issue! What do you think we should do, pin and potentially update deps for 0.4.16?

[jni]

Yeah, looks like all our CI is broken by this. 🤦

[Czaki]

From 4 hours it will fail also on conda: conda-forge/pydantic-feedstock#64

@jaimergp it is possible to patch napari conda feedstock to block pydantic 1.10.0 for a few last releases if fix time will increase?

[uschmidt83]

Also breaks CI for stardist-napari: https://github.com/stardist/stardist-napari/actions/runs/2958470116

[Czaki]

@uschmidt83 It will break all CI that depends on napari.

But pydantic maintainer agrees that this is deprecation that should be fixed. pydantic/pydantic#4454 (comment)

And I have prepared PR with fix pydantic/pydantic#4455, so hopefully, it will be fast merged, and a bugfix release will be created. We need to wait.

If you cannot wait, then add pydantic!=1.10.0 to your test requirements.

[samuelcolvin]

Thanks so much for reporting this.

The issue is fixed and a patch release v1.10.1 is building now.

As per pydantic/pydantic#4359 I'm trying to test popular packages which make extensive use of pydantic against pre-releases before making new releases to reduce the risk of breaking changes (like this 🤦).

Prior to future releases I'd love support from the community to test new pydantic versions with napari.

[Czaki]

We have pre-releases test, that even catches this problem, but it fails so often that, unfortunately, we, unintentionally, start to ignore it.

We need to find a better way to handle pre-release failure and will be happy to take additional care when pydantic pre-release is available.

[alisterburt]

Thank you for sorting this out so quickly @samuelcolvin and @Czaki!

@Czaki pointed out this morning that our pre-tests did actually catch this... 8 days ago: https://github.com/napari/napari/runs/7963696182?check_suite_focus=true

we haven't been good about catching issues like this because they fail so often - we will put in place some process to make sure problems like this are caught earlier in future! 🙂

[samuelcolvin]

That would be great, thanks so much.

[Czaki]

1.10.1 landed on pypi 🚀

[gtamazian]

The bug is caused by @lru_cache being applied to get_colorized_svg(): the decorator requires all input arguments of the function to be hashable and pydantic.color.Color values do not satisfy that requirement. One way to fix the bug is to remove @lru_cache from get_colorized_svg().

It would be also worth updating the type signature for the second argument of get_colorized_svg() by changing

def get_colorized_svg(path_or_xml: Union[str, Path], color: str = None, opacity=1) -> str:
    ...

to

def get_colorized_svg(path_or_xml: Union[str, Path], color: Optional[Union[str, Tuple[str, str]]] = None, opacity=1) -> str:
    ...

[samuelcolvin]

???

pydantic.color.Color is now hashable, just use pydantic!=1.10.0.

[gtamazian]

@samuelcolvin Thank you for pointing out the current status of pydantic.color.Color. I have updated pydantic in my working enviroment to version 1.10.1 and the original bug in napari seems to be solved by that. I suppose that no changes in the napari source code are required now, thanks to the timely release of the new version of pydantic.

[Czaki]

@gtamazian, there are still changes required (update signature or update call), but I address them in #4997

Close this Issue as solved.

Thanks, @samuelcolvin, for the fast reaction.