import h5py spits out OpenMPI messages to stderr

[jrollins]

The latest version of h5py is very annoying spitting out messages to stderr on import:

servo:~ 0$ python3 -c 'import h5py; print(h5py.version.info)'
--------------------------------------------------------------------------
[[27612,1],0]: A high-performance Open MPI point-to-point messaging module
was unable to find any relevant network interfaces:

Module: OpenFabrics (openib)
  Host: servo

Another transport will be used instead, although this may result in
lower performance.

NOTE: You can disable this warning by setting the MCA parameter
btl_base_warn_component_unused to 0.
--------------------------------------------------------------------------
Summary of the h5py configuration
---------------------------------

h5py    2.10.0
HDF5    1.10.4
Python  3.7.5 (default, Oct 27 2019, 15:43:29) 
[GCC 9.2.1 20191022]
sys.platform    linux
sys.maxsize     9223372036854775807
numpy   1.16.5

servo:~ 0$

It's really not ok for python libraries to be writing to stderr or stdout on import, other than for deprecation warnings. This definitely disrupts it's usage in command line utilities.

It looks like something coming from somewhere below the python layer, but either way it should not be exposed to the users of the python layer. The message also does not really explain how to get rid of it.

This is on Debian unstable, and the issue has been reported to the debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944192

Thanks!

[tacaswell]

I don't think we can do anything about that message. h5py does not have any direct dependency on OpenFabrics and to my knowledge we don't provide wheels that are linked against it.

I don't think h5py is directly triggering anything related to MPI based on that code path (the only place we import mpi4py is hidden inside of a function). From reading the debian bug tracker this appears to be dependent on how libhdf5 is built (if MPI it is built against an MPI implementation) on the debian side. The MPI related setup is likely being done by libhdf5, in a way that I believe is dependent on how it is built.

If we did capture and suppress warning messages from the underlying libraries, I suspect we would get a slew of bug reports complaining that we did so and hence hid critical debugging messages from them.

Sorry to give you the run-around, but I think this has to go back to debian unless you can reproduce this in a clean enviroment using the wheels we publish to pypi. I suspect that you will have to talk to the packagers of libhdf5 and/or openib.

I am inclined to close this with no action, but will wait for additional input.

---

Related, if we change the format of the version string is that going to cause problems for you?

[jrollins]

I don't think we can do anything about that message. h5py does not have any direct dependency on OpenFabrics and to my knowledge we don't provide wheels that are linked against it.

I don't think h5py is directly triggering anything related to MPI based on that code path (the only place we import mpi4py is hidden inside of a function). From reading the debian bug tracker this appears to be dependent on how libhdf5 is built (if MPI it is built against an MPI implementation) on the debian side. The MPI related setup is likely being done by libhdf5, in a way that I believe is dependent on how it is built.

Ok, thank you for confirming that. Do you have suggestions on how we can confirm where the issue is coming from?

But to be clear, are you sure that it doesn't have anything to do with how h5py is using libhdf5?

If we did capture and suppress warning messages from the underlying libraries, I suspect we would get a slew of bug reports complaining that we did so and hence hid critical debugging messages from them.

Yes, I agree it's tricky. But it sounds like it's really an issue with libhdf5, so it should be dealt with there.

Related, if we change the format of the version string is that going to cause problems for you?

Are you asking about problems with the debian packaging? I think it depends on how crazy you make it. Semantic versioning is certainly the easiest to deal with.

[tacaswell]

I missed one other mpi4py import in h5p.pyx which is not hidden (and apparently we can not further hide d0d7a19). It is possible that importing h5py.h5p (which is done in h5py/__init__.py) is enough to make mpi4py try to initialize its self which it turn causes OpenFabrics to complain that no suitable interconnect is available.

The more I think about this, the more I think that this is fundamentally a packaging problem and debian should not be packaging h5py with MPI enabled by default.

But to be clear, are you sure that it doesn't have anything to do with how h5py is using libhdf5?

I am not an openMPI expert so can not be completely sure, but given that we do not have any code that actively does any mpi setup, I am reasonably confident that there is nothing we can easily do from the h5py side of things.

---

I mean are you parsing the output of print(h5py.version.info)?

[jrollins]

I missed one other mpi4py import in h5p.pyx which is not hidden (and apparently we can not further hide d0d7a19). It is possible that importing h5py.h5p (which is done in h5py/__init__.py) is enough to make mpi4py try to initialize its self which it turn causes OpenFabrics to complain that no suitable interconnect is available.

The more I think about this, the more I think that this is fundamentally a packaging problem and debian should not be packaging h5py with MPI enabled by default.

Hrm ok. How is the enabling of MPI controlled in h5py? I would like to bring a concrete suggestion of how to change the packaging to the debian package maintainers.

I mean are you parsing the output of print(h5py.version.info)?

No, I only included the output of that command because this gitlab issue tracker asked for it, and it happened to also illustrate the problem ;)

[tacaswell]

https://h5py.readthedocs.io/en/stable/mpi.html is the canonical docs on h5py + mpi4py . In short, it requires explicitly asking for the parallel versions at compile time.

[takluyver]

Closing as there's nothing for h5py to fix. We can reopen this if we figure out there is something, but for now I agree with @tacaswell - this is coming from some other code, and it's not a good idea for us to try to redirect stdout stderr to hide the message.