Add h5py to `extra_requires` and set minimum version to 3.0.0

[IAlibay]

Follows up from discussions here: conda-forge/mdanalysis-feedstock#43

Since h5py can be installed via PyPI we should add it to our setup.py as an extra requirement. Also we should set the minimum version to 3.0 so we can drop the ValueError check which had to be included for backwards compatibility here: #3025

[orbeckst]

I don't know how fast h5py is moving. Maybe 2.x is still common? I also don't have a huge problem with leaving the simple 2.x/3.x compatibility in the code for a while, at least until our 3.0.

I'd be careful to apply NEP29 to anything everything (EDIT... English is hard) in the eco-system. It's fine for numpy, scipy & friends who signed up for it, I don't know for other projects. But maybe that's a separate discussion.

[IAlibay]

So there have been 8 minor releases since 2.10.0 (we're currently on 3.7.0). I don't mind offering backwards compatibility if we want, as far as I can tell everything works for now (although we haven't run tests on the minimum versions in a long while).

[orbeckst]

We can't really test all ranges of versions of all support libraries, that's just a terrible combinatorial explosion. Checking minimum numpy is crucial but for most other things I think we can keep the known minimum versions as we have. We still have things like matplotlib >= 1.5.1 in our setup.py... Typically this minimum version encodes some specific reason of why we pinned it there.

I'd follow a conservative approach in raising versions for anything that doesn't explicitly adapted NEP29 for their own project. "If it ain't broke don't fix it:" keep our minimal version unless

• we get a bug report that shows problems with the minimal version
• we find it unsustainable to support the minimal version

If a dependency has signed up for NEP29 then I'd treat them as another numpy-like dependency.

[IAlibay]

We can't really test all ranges of versions of all support libraries, that's just a terrible combinatorial explosion.

It's a linear thing you don't need to combine. It's something we could easily drop into our weekly Cron, it adds N requirements worth of runners but imho it's a good idea to check the minimum versions are even working

I'd follow a conservative approach in raising versions for anything that doesn't explicitly adapted NEP29 for their own project. "If it ain't broke don't fix it:" keep our minimal version unless

• we get a bug report that shows problems with the minimal version
• we find it unsustainable to support the minimal version

I disagree. This approach leads to historical artifacts / compatibility code bits that just are there "because we didn't check". Imho if we set minimum version then we should at least do a minimum due diligence to check it works.

[orbeckst]

It's a linear thing you don't need to combine. It's something we could easily drop into our weekly Cron, it adds N requirements worth of runners but imho it's a good idea to check the minimum versions are even working

You mean, we try each minimum version in turn within the background of "latest" version (or version pulled in by the dependency resolution algorithm)? That sounds feasible, especially on an infrequent CRON CI job.

Imho if we set minimum version then we should at least do a minimum due diligence to check it works.

Well, it's hard to argue with you when you have the (moral) high ground ;-). It's more professional that we test instead of waiting for users to complain.

It would be good if, at the end of discussions, we have an idea how we will normally deal with setting/increasing minimal versions and with testing — is it going to be NEP29 all the way?

In the broader context this touches on the discussion on required/optional dependencies — for a comprehensive "Dependency Rules for MDAnalysis".