System property "python.hom"...

Anonymous
2010-06-22
2013-03-15

  • Anonymous
    2010-06-22

    I have PyDev installed with Oracle Enterprise Pack for Eclipse (OEPE) and running into a problem with
    a Weblogic WLST jython script.  An exception was thrown complaining in-compatible Jython module, etc.
    The script is executed with a Weblogic WLST interpreter instantiated by OEPE plugin
    (not through the PyDev interpreter configuration)

    After some debugging, it turns out the problem was caused by  System property "python.hom" set by PyDev,
    which causes the Jython modules bundled by PyDev picked up by WLST.
    Since WLST is based on different version of Jython, an exception was thrown.

    Is this a bug? I understand PyDev needs the bundled Jython
    for design time support, but is there a way to avoid using system property
    which may causes problem like this, which is very hard to debug.

    sys.path

     
  • Fabio Zadrozny
    Fabio Zadrozny
    2010-06-22

    Jython does have some static initialization that's needed - and that's where pydev sets the python.home and python.path environment variables, but I'm really not sure how or why it's affecting the OEPE without taking a look at their source code and how they deal with things there…

    Does this happen because they also have a Jython inside of eclipse or when launching a script outside of eclipse? (if it's out of eclipse, it should work, as they *should* be properly managing the python.path and python.home passed to the new process, as pydev itself does when launching jython scripts  - now, if it's inside of eclipse, I really wouldn't know without researching more and probably needing to take a look in their code).

    Cheers,

    Fabio

     

  • Anonymous
    2010-06-22

    Yes, for performance reason, OEPE does instantiate Jython based WLST inside of Eclipse.  Actually there could be even multiple instances of them since user may have multiple server configured, although will be in different classloader.

    For now I am using this workaround, which basically removes the python.home and python.path env variable before creating the WLST instance, then restore them (for PyDev) after done .  But a better solution will be eliminating the need for the global
    env variable in PyDev, if possible.

    Thanks,

    Danny