[ pyopengl-Bugs-2903797 ] 3.0.1a3 imports throw OSError

"SourceForge.net" <[email protected]> Mon, 22 Feb 2010 17:14:26 +0000
Newsgroups gmane.comp.python.opengl.devel
Message-ID <[email protected]>
Bugs item #2903797, was opened at 2009-11-25 10:33
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Silverstein (herc111)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: 3.0.1a3 imports throw OSError

Initial Comment:
We recently upgraded to 3.0.1a3 from 2.0.2.01.  In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError.  With v3.0 it now raises an OSError.  Shouldn't this throw an ImportError?

We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used).  There are situations where users run our software and don't have GL libraries (like on a head node of a cluster).  To handle these circumstances we have been checking for ImportError's.  Unless I'm missing something this seems like the correct exception to raise.


----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2010-02-22 12:14

Message:
I believe we've fixed this, I'm closing, please re-open or re-submit if
there's something missing.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2010-02-22 03:25

Message:
7WdxGn  <a href="http://piclnsjhsfkg.com/">piclnsjhsfkg</a>,
[url=http://thbtiuizqofy.com/]thbtiuizqofy[/url],
[link=http://xghvtjahrsti.com/]xghvtjahrsti[/link],
http://efevnryauvnd.com/

----------------------------------------------------------------------

Comment By: Silverstein (herc111)
Date: 2009-11-25 15:36

Message:
Mike, ImportError for GL and null func errors for GLU sounds great.

With the holiday this week I won't get to test this until next week at the
earliest.  Will post back the results.

----------------------------------------------------------------------

Comment By: Silverstein (herc111)
Date: 2009-11-25 15:08

Message:
I guess this change in behavior between pyopengl 2 and 3 is due to the use
of ctypes where ctypes is throwing an OSError whereas prior to using ctypes
it threw an ImportError.

Unfortunately, for us we can't control where users will run our software.
Some of our software requires OpenGL (and in those cases it isn't an
issue).  In some of our tools the use of OpenGL is a nice additional
feature, but if for some reason it isn't available, then we try, as much as
possible, to continue to allow the python scripts to work (ie be usable by
the user but with somewhat diminished feature sets).  In these cases we
need to trap the failed imports of the GL/GLU libraries.

It sounds like you don't want to catch and then throw an ImportError and
that you feel the right way to do this would be to NULL out the functions,
but that this is a lot of work (which I can see).  I take that to mean that
this won't be fixed.  If that's the case, we'll try to put our own
try-except catches into our own python classes.

BTW,  we've been very happy with PyOpenGL.  So thanks!

Herc




----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 15:07

Message:
Okay, I'm going to punt on the "No GL" case and raise an ImportError.  The
no GLU case on GLX and WGL platforms will now produce null-function errors
on attempts to call GLU functions (as with GLUT or GLE).  This is all in
bzr head now, if you could test in environments where this can actually
happen it would be helpful to me.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 14:51

Message:
Hmm, I can see where the error is coming from, but it seems that the
correct approach would be that taken for the rest of the libraries (GLE and
GLUT), i.e. no import error, just a lot of NULL functions... thing is
there's lots of code that is going to fail because e.g. it tries to load
error handling functions.  Quite frankly I never considered the failure
case of "no GL" or a "GL without GLU" platform.

----------------------------------------------------------------------

Comment By: Silverstein (herc111)
Date: 2009-11-25 14:17

Message:
Sorry about that.  I should have added that to the case.  I've done that
now.  Note that this is being run through our run-time environment, but
this would happen even if we did a direct OpenGL.GL import (which can be
seen in the stack trace).

The culprit seems to be that the _dlopen generates an OSError.  While
strictly speaking that may be the case, as a user of the module I would
have simply expected an ImportError.s.

On a perhaps somewhat related note I noticed that if I try to import just
GL but don't have a valid GLU library, that it complains.  I would have
thought that importing just GL would not try to load the GLU library. 
Should I file a separate bug case for that?

Thanks,

Herc


----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-11-25 14:06

Message:
Hmm, can you tell me *where* the OSError comes from (precisely, as in a
traceback).  It would make it much easier to catch the OSError.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&group_id=5988

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net