check for complete pyside presence before trying to import #2757
Conversation
importing pyside partially and then falling back to pyqt causes a crash in sip (see ipythongh-1431) To avoid it try to locate all modules before the import and should that fail print a warning.
| @@ -35,6 +44,11 @@ def prepare_pyqt4(): | |||
| prepare_pyqt4() | |||
| import PyQt4 | |||
| from PyQt4 import QtCore, QtGui, QtSvg | |||
| if pyside_found: | |||
There was a problem hiding this comment.
Under what condition does it reach this point with pyside_found=True? It looks like, if it can't find the modules it needs, ImportError is raised while pyside_found is still False.
There was a problem hiding this comment.
find_module does not load the module.
It is possible that one of these module is on the disk but can't be loaded, if the others load it will likely still crash so a warning is printed.
There was a problem hiding this comment.
What would prevent them being loaded? Permissions error? How could that arise? I think it's OK to handle these corner cases in the main code base, I just want to work out what it is we're dealing with.
Am I right in thinking that you're handling two different cases here? The section above using find_module avoids loading the PySide modules unless all the ones we need are present, so that we can fall back to PyQt4 if some are missing. That bit I think I follow. This second addition I'm more hazy about.
There was a problem hiding this comment.
its pretty paranoid, but plenty things could happen e.g. undefined symbols due to linking errors, all kind of issues due to binary incompatibilities.
but as qt is a pretty core package if its broken you probably have bigger issues than ipython then, so the warning could be dropped.
There was a problem hiding this comment.
That's fair enough. I guess my concern is that if we don't know a likely reason for this result, any suggestions in the message are liable to be unhelpful. But I guess a general "your dodgy PySide installation is a likely culprit" is better than nothing.
I'm happy for this to go in.
|
as this is a debian only problem I'm fine with carrying that patch in the package alone (or change the package to depend on the complete python-pyside metapackage) |
|
@takluyver I recommended that @juliantaylor open a PR, even if it only ends up as a debian patch, just so we have a record of it. The disadvantage of merging it is we are taking responsibility for a package-management issue. The advantage is this issue can still come up for IPython installed manually on a debian system with incomplete pyside. |
|
I'm indifferent to the proposed patch. Go ahead and merge it if you like. |
|
We all seem to be ambivalent about merging this. On the plus side, users who install IPython on Debian-based systems outside apt would benefit from it. The downside would be a little extra complexity to handle an odd corner case. I suggest we merge it. The complexity would exist anyway, just as a Debian patch, and I think it's a good idea to minimise the amount of patches we make distributions apply. @bfroehle , @minrk : any objections? If not, I'll merge this tomorrow. |
|
No, it's fine with me. |
|
Sounds good to me. |
check for complete pyside presence before trying to import
…o import importing pyside partially and then falling back to pyqt causes a crash in sip (see gh-1431) To avoid it try to locate all modules before the import and should that fail print a warning. debian splits pyside into many small packages so sometimes people end up with incomplete pyside installations.
check for complete pyside presence before trying to import
importing pyside partially and then falling back to pyqt causes a crash
in sip (see gh-1431)
To avoid it try to locate all modules before the import and should that
fail print a warning.
debian splits pyside into many small packages so sometimes people end up with incomplete pyside installations.