Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure

Drew Parsons dparsons at debian.org
Mon Mar 2 16:33:24 GMT 2020


On 2020-03-02 23:58, Thibaut Paumard wrote:
> Hi Drew,
> 
> I see, so you effectively copy all symbols from _h5py except those that
> look like __foo__ which is Python internal stuff, *and* you give them 
> an
> entry under h5py in sys.modules. Nice, that should be pretty stable.

Thanks for reviewing, Thibaut.  Actually it was more or less trial & 
error, adding these various elements until (a) import h5py worked, and 
(b) the tests loaded and ran.

I tried "from h5py_serial import *", but that misses the _weak_private 
elements. importlib wouldn't get them either, even when explicitly 
requested. setattr/getattr loaded them, so I figured might as well do 
the same with public api for consistency, instead of "import *".

I also tried the original idea of testing "if MPI_ACTIVE" in the code 
where mpi4py is being loaded.  I could get it to work but it didn't 
provide the serial start time speed up that our Bug Submitter is asking 
for.

> Actually, you don't treat public_api differently from weak_privates, 
> and
> you could be missing some symbols (if introduced later) of the form
> _foo_, _foo__ or __foo_. You could simplify the code and cope with this
> possibility with something like:
> 
> api=[ k for k in _h5py.__dict__.keys() if not (k.startswith('__') and
> k.endswith('__')) ]

I see, with double underscore __ instead of single _. I'll do that.

> Like you, I would keep h5py_serial and h5py_mpi separate rather than
> submodules of h5py. Mostly because the h5py folks could in the future
> want to use those two names and do it in an incompatible manner.

Fair enough, I'll keep them separate. (actually, I'll file an Issue 
upstream and let them know what we've done. They may want to adapt for 
themselves).

Thanks again for the review.

Drew



More information about the debian-science-maintainers mailing list