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

[Duncan Grisby]

On Friday 1 August, James Henstridge wrote:

> Providing a module called "CORBA" is part of the standard Python CORBA 
> mapping:
>     http://www.omg.org/cgi-bin/doc?formal/02-09-07
> 
> Before version 1.99.5, pyorbit just created a CORBA module as a side 
> effect of importing the ORBit module.  It now provides a dummy CORBA.py 
> that will initialise pyorbit, to better follow the spec.
> 
> Do any of the Python ORBs in Debian coexist?  The standard language 
> mapping doesn't address this problem at all.

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.

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.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --