Scipy.signal.gaussian import from Process 0.8.0 to 0.9.0 broken

CADET Troubleshooting
1

Updated to the new Process 0.9.0 release and some import commands are now broken - even went so far as to make a new environment, reinstall cadet and cadet process

from CADETProcess.modelBuilder import SMBBuilder
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

ImportError: cannot import name 'gaussian' from 'scipy.signal'

After further inspection, they all seem to tie to Scipy.signal.gaussian, which i believe should be scipy.signal.windows.gaussian

2

Thanks for reporting this. We’ll create a bug-fix release ASAP.

3

Hey,

just confirmed that it’s not a CADET-Process bug. It’s produced between ArviZ<=0.17 and scipy>=1.13, as mentioned here. And one of our dependencies (hopsy) usess ArviZ, so that’s where the error comes from.

Luckily, ArviZ==0.18 fixes the import error and is available on both pip and conda-forge, so it should be resolvable by upgrading ArviZ. If that doesn’t work for you, please let me know and we can look further into it.

2 Likes
4

Thanks for tracking that down - it turns out I was building my environments in Python 3.9.19, and Arviz==0.18 has a Python >3.10.0 dependency, so it wasn’t updating. Updating to Python 3.12.2 still gave an error, and a different one upon building a new environment, something to do with the hopsy wheel failing.

Rebuilt the environment in Python 3.11.8, the environment built correctly and the SMB Builder example worked just fine.

Maybe all that is to say, CADET Process should have a Python dependency between 3.10 and 3.11?

5

I do understand your reasoning, however, we do support 3.9 - 3.12 in terms of language-specific features and also test this in our CI on Github. Sometimes there are some hiccups with upstream dependencies, but usually they get resolved quite quickly.

On a related note, hopsy currently brings in a lot of dependencies since it relies on polyround which itself has more dependencies than it should have. We’d love to improve this in the future and if you have some funding or personnel who are into deep linear algebra, please let us know.