[omniORB] Re: [pygtk] Conflicting omniORBpy and PyORBit

[James Henstridge]

On 01/08/03 21:13, Duncan Grisby wrote:

> omniORB's CORBA module really lives in omniORB.CORBA, so you can do
>
>"from omniORB import CORBA" instead of just "import CORBA". I believe
>Fnorb does the same thing, so it should be considered a de-facto
>standard. It would be good if pyorbit supported the same model.
>
>The standard Python mapping says
>
>  "An IDL module is mapped into a Python module. Modules containing
>   modules are mapped to packages (i.e., directories with an __init__
>   module containing all definitions excluding the nested modules). An
>   implementation can chose to map toplevel definitions (including the
>   module CORBA) to modules in an implementation defined package, to
>   allow concurrent installations of different CORBA runtime
>   libraries. In that case, the implementation must provide additional
>   modules so that toplevel modules can be used without importing them
>   from a package.
>  "
>
>So omniORB and Fnorb's behaviour is permitted if not exactly mandated.
>
That is what PyORBit is doing now too, with the exception that once you 
import one of the PyORBit modules, the modules named "CORBA" and 
"PortableServer" will point at the PyORBit versions.

>
>The only issue for packagers is how to deal with the top-level CORBA
>(and PortableServer, etc.) modules. One solution would be to install
>them only if they are not already there from a different ORB.
>  
>
Yep, and that seems to be a problem for distributors wishing to package 
multiple Python ORBs.  I am not sure what the right choice here is.

James.

-- 
Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/