ImportError due to incorrect version checking #1002

Closed
rabernat opened this Issue Nov 15, 2011 · 8 comments

Comments

Projects
None yet
4 participants
@rabernat

Trying to run ipython 0.11 with pyzmq support. I have pyzmq v 2.1.10 intstalled. I have tried various hacks to get around this, but I don't really know how to fix it. The problem comes up at various places in building and at runtime, and I have been able to employ various hacks to get around it. But the core of this issue is this:

ImportError: IPython.zmq requires pyzmq >= 2.1.4, but you have 2.1.10

The problem is that the way the version checking is done, for example in IPython/zmq/init.py, doesn't consider the possibility of two-digit version numbers. In python, '2.1.10' >= '2.1.4' evaluates to False! Apparently a more sophisticated method for version checking is needed.

I think I could actually manage to fix this myself, but I have never contributed to an open source project and don't really know how it works. So I thought I would submit this bug instead...

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 15, 2011

Member

Please search for existing issues before posting duplicates (#870, #874). This was fixed in master by PR #758. If you need to use 0.11, the solution is to force install pyzmq 2.1.9 (easy_install pyzmq==2.1.9), or tweak your IPython.zmq.__init__.py to just skip the version check (the same goes for IPython.parallel.__init__.py, if you plan to use it).

Member

minrk commented Nov 15, 2011

Please search for existing issues before posting duplicates (#870, #874). This was fixed in master by PR #758. If you need to use 0.11, the solution is to force install pyzmq 2.1.9 (easy_install pyzmq==2.1.9), or tweak your IPython.zmq.__init__.py to just skip the version check (the same goes for IPython.parallel.__init__.py, if you plan to use it).

@rabernat

This comment has been minimized.

Show comment
Hide comment
@rabernat

rabernat Nov 15, 2011

Sorry! I tried to seach first but didn't find those existing issues.

Sorry! I tried to seach first but didn't find those existing issues.

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 15, 2011

Member

No worries, GitHub's Issue search is not awesome, so it's best to have short queries - like 'pyzmq 2.1.10', or 'IPython.zmq requires'.

Member

minrk commented Nov 15, 2011

No worries, GitHub's Issue search is not awesome, so it's best to have short queries - like 'pyzmq 2.1.10', or 'IPython.zmq requires'.

@minrk minrk closed this Nov 15, 2011

@giskarda

This comment has been minimized.

Show comment
Hide comment
@giskarda

giskarda Nov 24, 2011

Please review and apply this patch :)

rsetti@IRL-ML-RICCARDO:~ $cat zmq-init.patch 
--- /Library/Python/2.7/site-packages/ipython-0.11-py2.7.egg/IPython/zmq/__init__.py    2011-11-24 00:04:34.000000000 +0000
+++ __init__.py.bak 2011-11-24 00:00:55.000000000 +0000
@@ -10,7 +10,6 @@
 #-----------------------------------------------------------------------------
 
 import warnings
-from pkg_resources import parse_version as V
 
 minimum_pyzmq_version = "2.1.4"
 
@@ -21,11 +20,9 @@
 
 pyzmq_version = zmq.__version__
 
-cmp_result = cmp(V(pyzmq_version), V(minimum_pyzmq_version))
-
-if cmp_result == -1:
+if pyzmq_version < minimum_pyzmq_version:
     raise ImportError("IPython.zmq requires pyzmq >= %s, but you have %s"%(
-        minimum_pyzmq_version, pyzmq_version))
+                    minimum_pyzmq_version, pyzmq_version))
 
 del pyzmq_version

Please review and apply this patch :)

rsetti@IRL-ML-RICCARDO:~ $cat zmq-init.patch 
--- /Library/Python/2.7/site-packages/ipython-0.11-py2.7.egg/IPython/zmq/__init__.py    2011-11-24 00:04:34.000000000 +0000
+++ __init__.py.bak 2011-11-24 00:00:55.000000000 +0000
@@ -10,7 +10,6 @@
 #-----------------------------------------------------------------------------
 
 import warnings
-from pkg_resources import parse_version as V
 
 minimum_pyzmq_version = "2.1.4"
 
@@ -21,11 +20,9 @@
 
 pyzmq_version = zmq.__version__
 
-cmp_result = cmp(V(pyzmq_version), V(minimum_pyzmq_version))
-
-if cmp_result == -1:
+if pyzmq_version < minimum_pyzmq_version:
     raise ImportError("IPython.zmq requires pyzmq >= %s, but you have %s"%(
-        minimum_pyzmq_version, pyzmq_version))
+                    minimum_pyzmq_version, pyzmq_version))
 
 del pyzmq_version
@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 24, 2011

Member

@giskarda - I think your patch is backwards, but that is one approach for fixing 0.11. Of course, as mentioned above, this has been fixed in master for months.

Member

minrk commented Nov 24, 2011

@giskarda - I think your patch is backwards, but that is one approach for fixing 0.11. Of course, as mentioned above, this has been fixed in master for months.

@lgautier

This comment has been minimized.

Show comment
Hide comment
@lgautier

lgautier Nov 27, 2011

Wouldn't it have made sense to backport the fix made in the master to 0.11 and have a bugfix release then ?

Wouldn't it have made sense to backport the fix made in the master to 0.11 and have a bugfix release then ?

@minrk

This comment has been minimized.

Show comment
Hide comment
@minrk

minrk Nov 27, 2011

Member

Sure it would, and the same goes for the dozens of other bugfixes we have made since 0.11.

We are hoping to have a fairly short release cycle for the next few revisions as kinks are worked out after the major reorganization started in 0.11, and we decided to put all of our effort towards keeping that cycle short, rather than maintaining separate bugfix-only tracks alongside the feature work. We had intended 0.12 to be out by now, keeping this incompatibility window under a month. 0.12 should be within a few weeks, and 0.13 should follow not too long after.

Of course, the longer we take to cut 0.12, the greater the cost of not having done a bugfix release will be.

Member

minrk commented Nov 27, 2011

Sure it would, and the same goes for the dozens of other bugfixes we have made since 0.11.

We are hoping to have a fairly short release cycle for the next few revisions as kinks are worked out after the major reorganization started in 0.11, and we decided to put all of our effort towards keeping that cycle short, rather than maintaining separate bugfix-only tracks alongside the feature work. We had intended 0.12 to be out by now, keeping this incompatibility window under a month. 0.12 should be within a few weeks, and 0.13 should follow not too long after.

Of course, the longer we take to cut 0.12, the greater the cost of not having done a bugfix release will be.

@lgautier

This comment has been minimized.

Show comment
Hide comment
@lgautier

lgautier Nov 27, 2011

IPython 0.11 was released at the vey end of July 2011, and now 0.12 "should be" few weeks weeks away.
May be duplicate bug reports already indicate that bugfix releases (doesn't have to be to fix that problem alone) should indeed have been made.

Patching, bumping the release number (say, 0.11-1, 0.11-2, etc...), eventually adding tags in the repository, and pushing to Pypi might not be more work than that answering duplicated threads. ;-)

IPython 0.11 was released at the vey end of July 2011, and now 0.12 "should be" few weeks weeks away.
May be duplicate bug reports already indicate that bugfix releases (doesn't have to be to fix that problem alone) should indeed have been made.

Patching, bumping the release number (say, 0.11-1, 0.11-2, etc...), eventually adding tags in the repository, and pushing to Pypi might not be more work than that answering duplicated threads. ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment