Repository navigation
[1.3] version comparison fails with numpy 1.12.0b1 #5643
Description
With astropy 1.3 and numpy 1.12.0b1, many affiliated packages now fail in the tests when the numpy version number is compared. For example aplpy:
Traceback (most recent call last):
File "debian/tests/python3-aplpy", line 7, in <module>
import aplpy
File "/usr/lib/python3/dist-packages/aplpy/__init__.py", line 9, in <module>
from ._astropy_init import *
File "/usr/lib/python3/dist-packages/aplpy/_astropy_init.py", line 116, in <module>
from astropy import config
File "/usr/lib/python3/dist-packages/astropy/__init__.py", line 116, in <module>
_check_numpy()
File "/usr/lib/python3/dist-packages/astropy/__init__.py", line 104, in _check_numpy
from .utils import minversion
File "/usr/lib/python3/dist-packages/astropy/utils/__init__.py", line 20, in <module>
from .compat.odict import OrderedDict
File "/usr/lib/python3/dist-packages/astropy/utils/compat/__init__.py", line 14, in <module>
from .numpycompat import *
File "/usr/lib/python3/dist-packages/astropy/utils/compat/numpycompat.py", line 24, in <module>
NUMPY_LT_1_12 = not minversion('numpy', '1.12dev')
File "/usr/lib/python3/dist-packages/astropy/utils/introspection.py", line 159, in minversion
return parse_version(have_version) >= parse_version(version)
File "/usr/lib/python3.5/distutils/version.py", line 70, in __ge__
c = self._cmp(other)
File "/usr/lib/python3.5/distutils/version.py", line 337, in _cmp
if self.version < other.version:
TypeError: unorderable types: int() < str()
Activity
mhvk commentedon Dec 24, 2016
I put that
1.12devin to be able to test with the recent numpy, but maybe now it can be changed to just1.12?Although ideally we fix this in a better way...
mhvk commentedon Dec 24, 2016
Part of the problem is that how
parse_versionis imported inmin_version:The version from
pkg_resourcesworks fine, but that fromdistutils.versiondoes not.Anyway, an attempt to solve it in #5646.
mhvk commentedon Dec 24, 2016
So, possibly the solution is to depend on
pkg_resources...astrofrog commentedon Dec 25, 2016
We already have setuptools (well, pkg_resources) as an optional dependency for astropy.modeling.fitters I think, so maybe we could upgrade to having setuptools as a full required dependency.
mhvk commentedon Jan 7, 2017
I merged #5646, which should solve the problems for affiliated packages. Still not quite sure whether longer-term we should requite
setuptoolsor whether we should be stricter about what version numbers to use in the comparisons.bsipocz commentedon Jun 26, 2017
Closing as this seems to have been solved. Please reopen if you run into it again.