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

[James Henstridge]

On 15/08/03 02:01, Christian Reis wrote:

>On Thu, Aug 14, 2003 at 08:57:09AM -0400, Jon Willeke wrote:
>  
>
>>If you want to keep the convenience of a top-level CORBA module, perhaps
>>you could adapt PyGTK's version selection code: use a .pth file to set
>>the default ORB.  A program that knows it needs a specific ORB could
>>still import it explicitly.
>>    
>>
>
>This was a *very* serious support issue for PyGTK and I would *strongly*
>suggest we not incur in this overhead again.  I would much rather we had
>a specific module name for each CORBA module.
>
>What should be done is something like:
>
>    from PyORBit import CORBA
>
>which magically set things up so that the next
>
>    import CORBA
>
>loads the PyORBit version automatically. This is a matter of some
>sys.path hackery, as we do in ZODB -- ugly, perhaps, but a lot more
>effective than trying to steer people through a maze of sys.path
>problems. 
>  
>
This already works in pyorbit (although the module is "ORBit", rather 
than "PyORBit").

You can run "import ORBit" or "from ORBit import CORBA" with the latest 
version, and this will bind the toplevel module name CORBA.  The dummy 
CORBA.py simply imports ORBit, to bootstrap.

OmniORB does something similar, although I don't know if the CORBA 
module name gets bound when you import OmniORB.

The question is whether (a) should any ORB provide a toplevel CORBA 
module you can import without any other imports, and (b) whether this 
behaviour should be clarified in the spec.

James.

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