Ensure that NUMPY_LT_ constants are always defined - #3479

See my comment in #3478 - I do think you should let the import error be raised. If some package needs it in their setup, then the import error should actually happen. Note that this should never be a problem: before we just imported numpy during setup as well to construct the various NUMPY_LT_... strings.

I disagree--that's not really what the purpose of this function was. If someone needs to actually test that a module can be imported the current solution is to use an explicit import statement.

At some point I think there would still be value in having some sort of optional dependency manager a la #63. The scope of this function is intentionally very limited.

In other words, this should not be a replacement for

try:
    import scipy
    HAS_SCIPY = True
except ImportError:
    HAS_SCIPY = False

it's explicitly limited to just this case of checking for a specific minimum version of a package independent of whether any version of the package is available.

The problem is that with this function, say, NUMPY_LT_1_9 will be True is numpy is not present. It wouldn't seem this function's business to decide what should happen on an import error.

I guess I'm not sure, though, why you do the try/except at all. Is that necessary to resolve a problem? I ask mostly because I cannot see how whatever is resolved could have worked before, where numpy had to be imported just as much. (I do see why you need the string name, as this avoids importing numpy before the test is actually needed, but when the test has to be done, I don't see why you would hide the possible absence of numpy, surely something else will break too).

It's just so that I can define these constants regardless of whether Numpy is installed or not. I see what you're saying about NUMPY_LT_1_9 being True being confusing though. I think that's more a problem with the naming of that constant. In any case that only becomes an issue in cases where Numpy is actually not working, and that would be caught in the actual import statements well before the values of those constants matter.

It might be less of an issue if they were named more in accordance with the semantics of minversion. So instead of NUMPY_LT_1_9 have NUMPY_AT_LEAST_1_9 and so on. I just wanted to keep the number of changes at a minimum.

+1 to that, we should be using NUMPY_GE_1.9 for example

There are some cases where even this isn't quite right. For example, say there's a bug in Numpy 1.8.x (all versions) but it's fixed in Numpy 1.9.0.dev1234567. Then what we really want, to check for that bug, is specifically not minversion(numpy, '1.9.0.dev1234567') :( So even still this is just a first approximation.

right, I think we don't want to go overboard with the NUMPY_GT_1_6_BUT_LE_1_8_1_AND_ALSO_I_WANT_RASPBERRY_ICE_CREAM constants. If it's not a common case just using minversion directly makes more sense.