debug_on() could write relevant versions

[gerritholl]

Feature Request

Is your feature request related to a problem? Please describe.

Whenever I report a bug, I need to confirm what satpy version I am using. This is of course important, but it's also an extra step that could be semi-automated.

Describe the solution you'd like

I would like that debug_on() prints the relevant versions. When we report bugs, we anyway call debug_on(), so then this information enters the bug reports "for free".

Describe any changes to existing user workflow

None.

Additional context

[djhoese]

I think it would be better for check_satpy to do this since I believe we already request that in the issue template and it prints out information for what readers could and could not be loaded. We could do what other libraries like pyproj and xarray do where running this prints out a nice formatted list of dependencies and their versions. For example:

In [1]: import xarray as xr
xr.show
In [2]: xr.show_versions()
/home/davidh/miniconda3/envs/satpy_py39/lib/python3.9/site-packages/_distutils_hack/__init__.py:36: UserWarning: Setuptools is replacing distutils.
  warnings.warn("Setuptools is replacing distutils.")

INSTALLED VERSIONS
------------------
commit: None
python: 3.9.9 | packaged by conda-forge | (main, Dec 20 2021, 02:41:03) 
[GCC 9.4.0]
python-bits: 64
OS: Linux
OS-release: 5.15.8-76051508-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: 1.12.1
libnetcdf: 4.8.1

xarray: 0.20.2
pandas: 1.3.5
numpy: 1.20.3
scipy: 1.7.3
netCDF4: 1.5.8
pydap: None
h5netcdf: 0.12.0
h5py: 3.6.0
Nio: None
zarr: 2.10.3
cftime: 1.5.1.1
nc_time_axis: None
PseudoNetCDF: None
rasterio: 1.2.10
cfgrib: None
iris: None
bottleneck: 1.3.2
dask: 2021.12.0
distributed: 2021.12.0
matplotlib: 3.5.1
cartopy: 0.20.1
seaborn: None
numbagg: None
fsspec: 2021.11.1
cupy: None
pint: None
sparse: None
setuptools: 60.2.0
pip: 21.3.1
conda: None
pytest: 6.2.5
IPython: 7.30.1
sphinx: 4.3.2

[gerritholl]

You're probably right. I forgot about check_satpy(). The issue template as currently written instructs to use it only "when relevant" and only in the context of reader/writer dependencies (when I run check_satpy() with debug_on() I get a large load of debug info from numpy and numba).

[verduijn]

Is this something that's still wanted? I quickly checked the pyproj and xarray implementations and they seem to hard code the dependencies, so that would require some diligence to keep it synced with the pyproject.toml.

[mraspaud]

I think it would be nice! isn't there a way to use importlib for example to extract the version numbers?

[verduijn]

there is importlib.metadata.version which could be used to get the version numbers indeed, but what modules we check the version for would need to be hard coded (likely a copy of the dependencies section in pyproject.toml).

Glancing over the current check_satpy function I notice there is some try/catch import module checking going on for cartopy and geoviews which can be overwritten by setting your own extra=['module1', 'module2']. The function documentation also says it will return a bool thats true if all specified features are loaded successfully, but there are no return statements.

How much backwards compatibility do we want? If it's important we can add another 'module' keyword argument and add another print section and fix the comment. If it's less important we could also change the extra section to a modules one and start returning a bool from the function (or fix the comment).

[djhoese]

I would be OK with either check_satpy doing this or a separate show_versions() function. I am also OK with a hardcoded list of dependencies to check for the likely culprits of issues. The ones that come to mind are python, numpy, dask, xarray, gdal, rasterio, pyproj, netcdf4, h5py, pyhdf, h5netcdf, fsspec, and maybe a couple others I'm forgetting.

I think doing a simple <package>.__version__ would be simple enough, right?

[verduijn]

I think doing a simple .version would be simple enough, right?

To answer this question I checked this discussion and came to the conclusion that .__version__ will not work for arbitrary packages while importlib.metadata.version will, for the tradeoff that it requires specifying the 'distribution package' which can differ from the import name. Since we specify the 'distribution package' in the pyproject.toml file I think that is acceptable.

I've cobbled together a draft pr: #2913

I've renamed the 'extras' argument and used the packages @djhoese suggested + the ones that where 'extras'. This breaks backwards compatibility for this function, so not sure what the opinion is on that?

[mraspaud]

I suppose we can close this as solved in #2913
Feel free to reopen if needed.