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

[SourceForge.net <no...@so...>]

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: Open
Resolution: None
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: 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