OpenGL support

[Lucian]

Hello everyone,

I'm new to Pyinstaller and I'm considering using it in my projects. I
would like to ask for your support in taking a decision on this.

I'm especially interested in deploying applications based on PyOpenGl.
I've tried to use Pyinstaller in a toy project, and I could not get it
working with PyOpenGl (Ubuntu 8.04, Python 2.5, PyOpenGl 3.0.0-b1,
Pyinstaller 1.3). I've browsed the e-mail archive, and I've found
previous discussions on this issue, dating from April last year.
However, I could not find a solution. I've also found a post of
Giovanni Bajo (http://blog.vrplumber.com/index.php?/archives/2165-
PyOpenGL-3.0.0b4-available.html) from July this year stating he is
interested in adding support for PyOpenGl 3.

Does anyone have experience with PyOpenGl and Pyinstaller? Is work
being done to support PyOpenGl 3?
Please let me know if you have more insight in this.

Thanks!

Lucian

[Lucian]

I have done some additional experiments. One of the things I've tried
was to downgrade PyOpenGl to version 2.0.1.09. However, I've got the
same error message as before:

Traceback (most recent call last):
File "<string>", line 3, in <module>
File "/home/lvoinea/pyinstall/pyinstaller-1.3/iu.py", line 334, in
importHook
raise ImportError, "No module named %s" % fqname
ImportError: No module named encodings

Does anyone have a solution/advice on this?

Lucian

[Marco Bonifazi]

Try this one
http://www.bonifazi.eu/appunti/2008/04/pygtk-all-in-one-installer.html
If it is not up to date, please tell me, I'll do it.

--
Marco Bonifazi
http://www.bonifazi.eu

[Hartmut Goebel]

Lucian schrieb:

> Traceback (most recent call last):
> File "<string>", line 3, in <module>
> File "/home/lvoinea/pyinstall/pyinstaller-1.3/iu.py", line 334, in
> importHook
> raise ImportError, "No module named %s" % fqname
> ImportError: No module named encodings
>
> Does anyone have a solution/advice on this?

Is the encoding module available on your system at all (it should)? Try
python "import encodings" using the normal python interpreter.

If yes: Is the encodings module contained in the exe/dir? Use
ArchiveView to look inside the .PYZ (I expect no)

So find out which of the modules import encodings and implement hook
for it.

--
Schönen Gruß - Regards
Hartmut Goebel

Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

[Lucian]

>
> Try this onehttp://www.bonifazi.eu/appunti/2008/04/pygtk-all-in-one-installer.html

> If it is not up to date, please tell me, I'll do it.
>
> --

> Marco Bonifazihttp://www.bonifazi.eu- Hide quoted text -
>

Hi Marco,

I've took a look at the website and it refers to an all-in-one
installer fot pygtk. I use wxPython (2.8.7.1) as GUI library in my
projects. Do you suggest I should migrate to pyGtk ?

Lucian

[Lucian]

Hello Harmut,

> Is the encoding module available on your system at all (it should)? Try
> python "import encodings" using the normal python interpreter.
>
> If yes: Is the encodings module contained in the exe/dir? Use
> ArchiveView to look inside the .PYZ (I expect no)
>
> So find out which of the modules import encodings and implement hook
> for it.

I've gone through your recommendations and unfortunately they do not
apply.
The 'encodings' module is present in the PYZ. The problem seems to be
somewhere else.

I've also tried to go thorough the steps presented in
http://groups.google.com/group/PyInstaller/browse_thread/thread/4685df0373dbe11f/.
This is the output of my application:

# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
import marshal # builtin
import imp # builtin
import posix # builtin
dlopen("ssbb_cref/distssbb_cref/_struct.so", 2);
import _struct # dynamically loaded from ssbb_cref/distssbb_cref/
_struct.so
importHook(encodings, __main__, locals, None)
importHook trying encodings in None
doimport(encodings, None, encodings)
importHook(imp, archive, locals, None)
importHook trying imp in None
importHook done with imp archive None (case 2)
importHook(os, __main__, locals, None)
importHook trying os in None
doimport(os, None, os)
importHook(imp, archive, locals, None)
importHook trying imp in None
importHook done with imp archive None (case 2)
importHook(os, __main__, locals, None)
importHook trying os in None
doimport(os, None, os)
..found None
..found None
..found None

Traceback (most recent call last):
File "<string>", line 3, in <module>
File "/home/lvoinea/pyinstall/pyinstaller-1.3/iu.py", line 334, in
importHook
raise ImportError, "No module named %s" % fqname
ImportError: No module named encodings

If you have any suggestions please let me know. I'll try to digg into
this for a while.

Cheers,
Lucian

[Marco Bonifazi]

I remember a similar problem, in Windows.
I solved it in a crazy way: I copied from python/lib dir some .pyc that were modified when I executed my program (codecs.pyc, os.pyc, for example), and pasted them into the path of my application.
It worked, but I have been no time to understand what was the problem.

[Lucian]

Including the .pyc files in the application folder does not solve the
problem for me.

After some experiments and digging in the code of iu.py I came with
the following conclusions:

- PyInstaller does not support PyOpenGL from version 3.0.0 on. In
this version PyOPpenGL starts to use pkg_resources intenally, and
PyInstaller does not have support for this (http://www.mail-
archive.com/pyins...@googlegroups.com/msg00257.html). One may try
to use an older version of PyOpenGL (e.g, 2.0.1.09).

- I could not find a working distribution of version 2.0.1.09 (of
earlier) of PyOpenGL for Python 2.5.2. The only one I found with
support for Python 2.5 is python_opengl_2.0.1.09.dsg.1-0.3_i386.deb.
However, this contains a bug that prevents it from working on Python
2.5.2 (and 2.5.1 ?). This bug is marked as solved in version 3.0.0 of
PyOpenGL.

- The opengl.py rthook is only intended for PyOpenGL versions earlier
than 3.0.0. It uses internally the os module. If the hook is installed
before importing os, it generates in infinite loop. The recursion is
actually detected internally and interrupted. This leads,
nevertheless, to a failure in importing the os module and eventually,
the top module that triggered the import. In the above experiments,
this is the encodings module. One could prevent this from happening by
removing the os dependency in the openg.py hook. Here is a possible
implementation:


# Old code

"""
import os
lastdir = os.path.basename(os.path.dirname(fn))
if os.path.basename(fn) == "version" and os.path.splitext(lastdir)[1]
== ".pyz":
"""

# New code
l_list = fn.split('/')
l_base = l_list[-1]
if len(l_list)>1:
l_folder = l_list[-2]
if (l_base == 'version') and (l_folder[-4:] == '.pyz'):

In conclusion, if you have the latest versions of Python, PyOpenGL
installed, I recommend you to look for another way of distributing
your application. I have successfully managed to do that using
cx_Freeze. There is not so much documentation about that, but the
following links have provided all the necessary information for me:

http://wiki.wxpython.org/CreatingStandaloneExecutables
(search/google for cx_Freeze wxpython)

http://sourceforge.net/mailarchive/message.php?msg_id=703ae56b0805172030l7746a1c5kc206f00573fc8654%40mail.gmail.com
(search/google for [cx-freeze-users] PyOpenGL 3.0.0b1 Not Zip Safe )
Note: this applies to the installation method that uses the setup.py
script. There is where the suggested code should go in.

Cheers,
Lucian

[Andrea Gavana]

Hi All,

On 8/15/08, Lucian wrote:
> Including the .pyc files in the application folder does not solve the
> problem for me.
>
> After some experiments and digging in the code of iu.py I came with
> the following conclusions:
>
> - PyInstaller does not support PyOpenGL from version 3.0.0 on. In
> this version PyOPpenGL starts to use pkg_resources intenally, and
> PyInstaller does not have support for this (http://www.mail-
> archive.com/pyins...@googlegroups.com/msg00257.html). One may try
> to use an older version of PyOpenGL (e.g, 2.0.1.09).
>
> - I could not find a working distribution of version 2.0.1.09 (of
> earlier) of PyOpenGL for Python 2.5.2. The only one I found with
> support for Python 2.5 is python_opengl_2.0.1.09.dsg.1-0.3_i386.deb.
> However, this contains a bug that prevents it from working on Python
> 2.5.2 (and 2.5.1 ?). This bug is marked as solved in version 3.0.0 of
> PyOpenGL.

I don't use PyInstaller, so I am not sure the same workaround can
apply here. I stumbled upon the same problem with py2exe, which does
not support eggs file and friends, and I solved the issue by adding
these lines of code at the beginning of my application code:

pyOpenglName = "PyOpenGL-3.0.0b3-py2.5.egg"
setupToolsName = "setuptools-0.6c8-py2.5.egg"

if hasattr(sys, "frozen"):
if pyOpenglName not in sys.path:
sys.path.insert(0, os.path.join(sys.prefix, pyOpenglName))
if setupToolsName not in sys.path:
sys.path.insert(0, os.path.join(sys.prefix, setupToolsName))

By manually adding the eggs file in the distribution folder my app
runs happily also in executable mode.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

[Hartmut Goebel]

Andrea Gavana schrieb:

> By manually adding the eggs file in the distribution folder my app
> runs happily also in executable mode.

PyInstaller trunk supports zipimport.

Since I have no write access to the Wiki, I can not document it there :-(

Adding zipimport is easy: Just add 'support/_pyi_egg_extract.py' to the
Analyse() part of your .spec file, like this:

a = Analysis([os.path.join(HOMEPATH,'support/_mountzlib.py'),
os.path.join(HOMEPATH,'support/useUnicode.py'),
os.path.join(HOMEPATH,'support/_pyi_egg_extract.py'),
__testname__ + '.py'],
)

[Mike Fletcher]

On Aug 15, 6:25 am, Hartmut Goebel <h.goe...@goebel-consult.de> wrote:
...

> PyInstaller trunk supports zipimport.
>
> Since I have no write access to the Wiki, I can not document it there :-(
>
> Adding zipimport is easy: Just add 'support/_pyi_egg_extract.py' to the
> Analyse() part of your .spec file, like this:

This doesn't quite work for PyOpenGL 3.x, as it uses pkg_resources
entry
points to register its components. Without that registration you'll
get
errors saying that PyOpenGL can't find a platform implementation for
your platform. The analysis will copy the fragments of PyOpenGL into
the PYZ archive but it will be missing the egg-level registration.

I've just spent a few hours hacking about and have what looks like it
may prove to be a usable (though size-expensive) solution.

http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGL-ctypes/src/pyinstallertest/

To make it work, you have to do an:

easy_install -d dist/appname path\to.egg

for each egg you want to support. Unfortunately that seems to mess up
your system-level registrations, (there should be an easy-install
mechanism to prevent that). Eventually you could use pkg_resources to
get the list of all top_level.txt metadata elements from all installed
eggs, watch for those packages in your analysis and exclude them from
it, then do an egg install for each one automatically.

You'll also see the ctypes.util import in there, doesn't seem to get
noticed by the analysis, probably because it's hidden behind an entry
point or something like that. I don't consider this an elegant
solution. It *should* be possible to include the egg metadata into
the
PYZ file and write a custom importer that could use that information,
but this hack should allow people to figure out something elegant.

HTH,
Mike