Running the test suite emits 27 warnings

[pmeier]

See for example this CI run. Most of them seem to be because deprecated behavior is used or functionalities are not properly invoked.

[a-ws-m]

I think all of the PendingDeprecationWarning or DeprecationWarnings are from package dependencies (e.g. see the working directory for this warning, which is for autograph; it is not the autograph package that is raising the warning, as importlib and imp are Python builtins, but rather it is causing the warning to be raised). I think a solution may be to use newer versions of the packages that have these issues resolved, but unfortunately I have found that the dependency matrix has to be quite strict in order to ensure the packages are compatible with the correct version of numpy: tensorflow-probability uses an older version and therefore a lot of other packages need to use old versions also.

There are three other types of warnings, some of which are raised several times:

• UserWarning: Unable to detect statically whether the number of index_points is 1. As a result, defaulting to treating the marginal GP at ``index_points`` as a multivariate Gaussian. This makes some methods, like ``cdf`` unavailable. (from here) -- This is expected behaviour, and cdf is not needed.
• UserWarning: Converting sparse ... to a dense Tensor of unknown shape. This may consume a large amount of memory. (from here) -- Again, unfortunately this is due to a dependency. The giveaway is the name of the Tensor in the ... that I omitted: in each case, its name contains the word set2_set, which is one of the algorithms megnet implements, rather than unlocknn.
• CustomMaskWarning: Custom mask layers require a config and must override get_config. When loading, the custom mask layer must be passed to the custom_objects argument. (from here) -- I don't know where this comes from, and Google doesn't reveal much. To my knowledge, unlocknn does not implement any custom mask layers, so I do not see how this could be raised by the package.

These last three warnings can be suppressed using tf.logging.set_verbosity(tf.logging.ERROR), if you think that would be helpful for cleaning up the log files? My only concern is that I want to keep an eye out in case another warning pops up in the future.

[pmeier]

• This is expected behaviour, and cdf is not needed.

Expected as in "I want to test that the warning is raised" or rather "I know this raises a warning, but the call is actually correct"? If it's the first, I recommend pytest.warns to assert that this is happening. In the latter case, it might be beneficial to silence the warning locally for example with warnings.catch_warnings. Otherwise, as a user I would always be in doubt if I made a mistake and the warning relates to my code.

The last argument also applies to the other points you raised. If a user might hit these warnings, you should probably silence them locally. If they are only hit in the test suite you can also filter these directly by putting

addopts =
  -Wignore::UserWarning::Converting sparse ...

in your pytest configuration.

[a-ws-m]

I've added handlers for the warnings in the pytest configuration as well as the main __init__.py.