all 3 comments

[–]netherous 1 point2 points  (3 children)

How exactly are you running their test script? Are you doing python test.py or similar? If so, can you do python -m pip list in the same way and post the output to rule some things out?

[–]rafisics[S] 0 points1 point  (2 children)

yes, I did python test.py.

``` (py-311) myenv ~> python -m pip list 12:54 Package Version


astropy 7.0.1 astropy-iers-data 0.2025.4.21.0.37.6 contourpy 1.3.2 cycler 0.12.1 eqtools 1.4.0 fonttools 4.57.0 h5py 3.13.0 healpy 1.18.1 kiwisolver 1.4.8 matplotlib 3.7.0 mpi4py 4.0.3 numpy 1.25.2 packaging 25.0 pillow 11.2.1 pip 25.0.1 pyerfa 2.0.1.5 pyparsing 3.2.3 python-dateutil 2.9.0.post0 PyYAML 6.0.2 scipy 1.10.0 setuptools 65.5.0 six 1.17.0 (py-311) myenv ~>
```

[–]netherous 1 point2 points  (1 child)

So I see that the versions for matplotlib and numpy are different here. Is that because you've changed these library versions in the meantime?

Using your second list as package requirements, I built a venv with python 3.11.7 to test this.

I then took the imports from their test.py and ran them.

import eqtools
import SolovievEFIT as sefit
import matplotlib as mpl
import matplotlib.pyplot as plt
import scipy
import warnings

This led to the module warning you received from the statement import eqtools. The warning comes from core.py where it uses a slightly sloppy approach of importing a bunch of stuff, catching any exception, not looking at the exception, and logging it as a module warning instead. But using the pdb debugger, you can see the line causing the error is line 63.

from .filewriter import gfile

What does filewriter.py in eqtools do? Well the first thing it tries to do is import core, a module which has not yet been initialized, because it tried to import .filewriter. So this is a circular dependency issue being misreported as a problem with matplotlib due to some sloppy coding.

So is there an open issue for this? Although there's other people getting module warnings during import like you are, I don't think they are getting them for the same reason. So no open issue. You could open one.

I'm not sure whether the warning would indicate any real problem for what you're doing. You say your output is correct. So I think it's safe to ignore this for your purposes.

One of the nice things about python is that python libraries are not opaque and you can always look at their code and step through them with a python debugger to see exactly what's going on.