#224 3.0.1a3 imports throw OSError

v3.0.0
closed-fixed
GL (74)
5
2010-02-22
2009-11-25
Silverstein
No

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.

Discussion

  • 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.

     
  • Silverstein
    Silverstein
    2009-11-25

    Stacktrace

     
    Attachments
  • Silverstein
    Silverstein
    2009-11-25

    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

     
  • 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.

     
  • 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.

     
  • Silverstein
    Silverstein
    2009-11-25

    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

     
  • Silverstein
    Silverstein
    2009-11-25

    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.

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

     
    • status: open --> closed-fixed