Struggling to install

[Charlie]

Hi people,


I'm looking at various tools I could use to make a simple but fast display application on a fleet of machines I have to work with (centos 5.8, centos 6.5, soon newer centoses).

On a centos 6.5 test box I have altinstalled python3.4
then created a venv and entered it,
then installed  sip-4.16.4 and PyQt-x11-gpl-4.11.2

then grabbed the latest vispy repo and tried to run a few examples. I've been running into problems...
Most examples I run I get :

INFO: Could not import backend "PyQt4":
cannot import name 'QtOpenGL'
INFO: Could not import backend "PyQt5":
No module named 'PyQt5'
INFO: Could not import backend "PySide":
No module named 'PySide'
INFO: Could not import backend "Pyglet":
No module named 'pyglet'
INFO: Could not import backend "Glfw":
GLFW library not found
INFO: Could not import backend "SDL2":
No module named 'sdl2'
INFO: Could not import backend "wx":
No module named 'wx'
libEGL warning: DRI2: failed to authenticate
INFO: Could not import backend "EGL":
Not ready for testing
INFO: Could not import backend "Glut":
No module named 'OpenGL'
Traceback (most recent call last):
  File "signals.py", line 128, in <module>
    c = Canvas()
  File "signals.py", line 72, in __init__
    app.Canvas.__init__(self, keys='interactive')
  File "/root/Envs/env1/lib/python3.4/site-packages/vispy-0.3.0-py3.4.egg/vispy/app/canvas.py", line 136, in __init__
    self._app = use_app()
  File "/root/Envs/env1/lib/python3.4/site-packages/vispy-0.3.0-py3.4.egg/vispy/app/_default_app.py", line 39, in use_app
    default_app = Application(backend_name)
  File "/root/Envs/env1/lib/python3.4/site-packages/vispy-0.3.0-py3.4.egg/vispy/app/application.py", line 48, in __init__
    self._use(backend_name)
  File "/root/Envs/env1/lib/python3.4/site-packages/vispy-0.3.0-py3.4.egg/vispy/app/application.py", line 181, in _use
    'PyQt' % [b[0] for b in CORE_BACKENDS])
RuntimeError: Could not import any of the backends. You need to install any of ['PyQt4', 'PyQt5', 'PySide', 'Pyglet', 'Glfw', 'SDL2', 'wx', 'EGL', 'Glut']. We recommend PyQt

but during PyQt4 compilation I could see :

These PyQt4 modules will be built: QtCore, QtGui, QtHelp, QtMultimedia,
QtNetwork, QtScript, QtScriptTools, QtXml, QtOpenGL, QtSql, QtSvg, QtTest,
QtXmlPatterns, phonon, QtAssistant

and here is what I get when I try to import QtOpenGL

(env1)[root@test PyQt-x11-gpl-4.11.2]# python
Python 3.4.2 (default, Oct 26 2014, 10:29:02)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt4
>>> import QtOpenGL
>>> from PyQt4 import QtOpenGL
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'QtOpenGL'

I'm at a loss...

Could you please help ?
Brgds.

[John David Reaver]

Is there a yum package for PyQt4, particularly PyQt4.QtOpenGL or something similar (Ubuntu has a separate python3-pyqt4.opengl package, for example)? Maybe there are some hidden dependencies that will be installed if you install that package. Before you compile PyQt, you might need to have some dependencies like mesa installed for OpenGL to work.

If you go to the site-packages directory for PyQt4 (inside the virtualenv it is something like lib/python3.4/site-packages/PyQt4), is there a QtOpenGL.so file? If so, you can run ldd on that file to see if it has missing dependencies.

If you want to use the virtualenv route, you could install the development packages for qt4 so you know the requisite libraries are installed, then recompile PyQt4. Note that I am experienced with PySide, Arch Linux, and Ubuntu, so I don't know if this is a common or specific CentOS problem, and I don't know how PyQt4 is packaged for yum.

Lastly, I recommend using the Anaconda Python distribution, where installing PyQt4 is as simple as "conda install pyqt". You can download the lightweight version installer for Anaconda here: http://conda.pydata.org/miniconda.html. Anaconda is nice because a lot of other packages that need to be compiled in a virtualenv are pre-packaged and install quickly, like numpy and scipy.

I hope some of this helps! And I hope someone who has encountered your particular error can chime in :)

--
You received this message because you are subscribed to the Google Groups "vispy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vispy+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luke Campagnola]

On Sun, Oct 26, 2014 at 2:56 PM, Charlie <c.cu...@gmail.com> wrote:

and here is what I get when I try to import QtOpenGL

(env1)[root@test PyQt-x11-gpl-4.11.2]# python
Python 3.4.2 (default, Oct 26 2014, 10:29:02)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyQt4
>>> import QtOpenGL
>>> from PyQt4 import QtOpenGL
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'QtOpenGL'

This is strange--usually QtOpenGL is installed as a subpackage of PyQt4. Could you post the output of:

    print PyQt4.__file__

    print QtOpenGL.__file__

?

[Almar Klein]

> This is strange--usually QtOpenGL is installed as a subpackage of PyQt4.

I've experienced it quite often myself that I needed to explicitly
install QtOpenGL.

- Almar

[Luke Campagnola]

On Sun, Oct 26, 2014 at 4:42 PM, Almar Klein <almar...@gmail.com> wrote:

This is strange--usually QtOpenGL is installed as a subpackage of PyQt4.

I've experienced it quite often myself that I needed to explicitly install QtOpenGL.

But notice that he _can_ import `QtOpenGL`, it just isn't available as `PyQt4.QtOpenGL`

 

[Almar Klein]

> This is strange--usually QtOpenGL is installed as a subpackage
> of PyQt4.
>
>
> I've experienced it quite often myself that I needed to explicitly
> install QtOpenGL.
>
>
> But notice that he _can_ import `QtOpenGL`, it just isn't available as
> `PyQt4.QtOpenGL`

Ah, I see. Remind me to read an email properly before posting...

This is weird. If the QtOpenGL lib works, you can probably fix things
just by doing (before importing vispy)

PyQt4.QtOpenGL = QtOpenGL

- Almar

[Cyrille Rossant]

As John says, we highly recommend Anaconda (at least try it and see if it works for you...). Any other installation method is likely to be very painful.

[Charles Curtit]

Hi all,
thanks for your answers !

Ok will try, although that would not be my prefered way to go...
I would get conda, then get the vispy repo ?

On a side note it seems it's the entire PyQt thing that does not
install correclty, I found out I can't import QtGui from PyQt4 either
.... sob.


What's the status now for Qt5 support ? I found some noise made about
it early this year but not much more, although the code evidently
tests for it at import time.

Cheers,
Charlie

[Almar Klein]

> As John says, we highly recommend Anaconda (at least try it and see if
> it works for you...). Any other installation method is likely to be very
> painful.

I kind of hope that Vispy is easy enough to install on any Linux box ...
This seems to be a PyQt problem. We have many other backends, so it
could be worth trying another, like PySide, or GLFW.

> Ok will try, although that would not be my prefered way to go...
> I would get conda, then get the vispy repo ?

Yes. Install the latest vispy into the conda env.

> What's the status now for Qt5 support ? I found some noise made about
> it early this year but not much more, although the code evidently
> tests for it at import time.

PyQt5 should work.

- Almar

[Cyrille Rossant]

2014-10-27 10:52 GMT+01:00 Almar Klein <almar...@gmail.com>:

> As John says, we highly recommend Anaconda (at least try it and see if
> it works for you...). Any other installation method is likely to be very
> painful.

I kind of hope that Vispy is easy enough to install on any Linux box ...  This seems to be a PyQt problem. We have many other backends, so it could be worth trying another, like PySide, or GLFW.

And we get back to the backend issue again... PyQt is kind of the "default" backend and I hope we can change that eventually. It is a huge dependency and I would very much prefer a lighter backend like GLFW or a pure Python one. For GLFW, if binary packages don't already exist on all platforms, maybe we can build them ourselves (using conda recipes for example)?