Deprecation ImportWarnings when precompiling

[femtomc]

@ericphanson and I are working on an project which has PyMNE.jl has a dependency. When I precompile -- I get a large amount of deprecation warnings:

/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
  return f(*args, **kwds)
/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
  return f(*args, **kwds)
/usr/lib/python3/dist-packages/nose/importer.py:12: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  from imp import find_module, load_module, acquire_lock, release_lock
/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
  return f(*args, **kwds)
/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
  return f(*args, **kwds)
/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
  return f(*args, **kwds)
/usr/lib/python3/dist-packages/nose/importer.py:12: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  from imp import find_module, load_module, acquire_lock, release_lock
/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
  return f(*args, **kwds)

[palday]

Those are all on the Python side -- nothing to be done in terms of packaging.

However, you can tell Python to simmer down:

using PyCall
const python_warnings = pyimport("warnings")
python_warnings.simplefilter("ignore", py"DeprecationWarning"; append=true)
python_warnings.simplefilter("ignore", py"RuntimeWarning"; append=true)

You can also tell MNE itself to less verbose:

PyMNE.set_log_level("ERROR")

[ericphanson]

maybe PyMNE.set_log_level("ERROR") could be part of the __init__? Getting

<frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
<frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 2:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 2:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 7:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 7:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 8:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 8:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 4:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 4:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 3:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 3:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 5:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 5:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 6:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 6:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 9:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
      From worker 9:    <frozen importlib._bootstrap>:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject

isn't super fun, and PyMNE isn't even a direct dependency (it's a dependency of a dependency, and I'm not even using functionality from MNE), so as a user I'm not sure there's much I can do. Fair enough I'm not just a user and I could adjust one level upstream, but I don't really see why it can't be done at "the source"?

[palday]

@ericphanson I think the intermediate dependency should handle it.

There are two reason why I'm hesitant to auto-hide those warnings:

1. PyMNE really is supposed to give you the MNE experience (warts and all) in Julia. Basically, you take your old Python script, change the imports a bit for the new language (that's the magic of PyCall + the surface similarity of the two languages), s/mne/PyMNE/g/ and you're good to go.
2. The warnings here are actually potentially serious warnings. One of the gotchas with PyCall, alternative BLAS (e.g. MKL) in Julia, and NumPy (even within Python) is that they can hit different ABIs (not a typo) of some shared dependencies, depending on all sorts of compatibility things. When sharing data across languages (whether explicitly with PyCall or implicitly via BLAS/NumPY), this can cause serious and hard-to-debug problems. So it's good that the user sees them.

I would be open to a PR adding some of this (background + potential workarounds) to the documentation.