[omniORB] Package import troubles with omniORBpy

[Randy Wiser]

Just a guess, but I'd suggest you try using the omniidl switch -Wbpackage=sri.transport, or whatever package structure you're using.  Note that if you are using the -C switch as well, you'll probably need to change its argument also.

- Randy

At 05:53 PM 04/19/2000 -0700, Todd Valentic wrote:
>   Hi --
>
>   I'm trying to convert an existing python application that uses Fnorb to 
>   omniORB. I've got the omniORBpy distribution up and running fine, can
>   run the examples and some test code, etc. The problem that I'm now running
>   into deals with importing the modules produced by omniidl when they are
>   part of a heirarchial package. 
>  
>   The IDL interface specification, omniidl output and python implementation
>   code all reside in a directory named ${TOP}/sri/transport. My PYTHONPATH
>   points to TOP and access to the modules in the directories is usually
>   done by:
>
>   from sri.transport import foobar
>
>   Unfortunately, I'm having problems doing this with the omniORB classes.
>   I have an IDL file named TransportModule.idl that defines a number of 
>   classes, but as an example one is named ProcessGroup:
>
>   module TransportModule {
>     ...
>         interface ProcessGroup {
>           ...
>     };
>   };
>
>   Running this through omniidl -bpython results in the expected
>   TransportModule/ POA_TransportModule/ and TransportModule_idl.py files
>   being created. A client program would access the interface by importing:
>
>   from sri.transport import TransportModule 
>
>   However, the imported TransportModule at this point doesn't seem to have 
>   anything defined for itself. Doing a dir(TransportModule) at this point 
>   shows:
>
>   ['TransportModule_idl', '__builtins__', '__doc__', '__file__',
>   '__name__', '__path__']
>
>   where as if I go to the directory itself and 'import TransportModule' and 
>   look at the dir() output I get all the expected entries.
>
>   This code has been working for some time under Fnorb. It looks like
>   omniORB's module loading is more complicated, and I suspect the problem
>   lies with the omniORB.openModule() calls in the _idl.py file.
>
>   Does anybody include definitions like this or am I really bending things
>   out of shape here? Any input or suggestions are welcome!
>
>   Todd