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

[James Henstridge]

On 1/08/2003 4:01 PM, ml wrote:

>Hi,
>
>I want to have both omniORBpy and PyORBit installed in
>parallel.  The first, because I use it for my own
>applications, the latter, because some GNOME programs depend
>on python-gnome2 and therefore on PyORBit.  Unfortunately,
>both packages include a file
>/usr/lib/python2.2/site-packages/CORBA.py
>which leads to the conflict.
>
>What is the best solution?  What does the standard say?  How
>has this been dealt with in the past?  Some ideas:
>
>Moving one of the files to a subdirectory seems an easy
>thing, but applications cannot find their CORBA.py without
>setting the PYTHONPATH or am I wrong?  Setting the
>PYTHONPATH is not what users should have to do.
>
>Renaming one of the files would break application source
>code.
>
>Maybe one could rename CORBA.py to omniORBpy.py or
>PyORBit.py and do either
>
>import PyORBit as CORBA
>
>or
>
>import omniORBpy as CORBA
>
>That would break only one line of the application source
>code.  A symbolic link from either omniORBpy.py or
>PyORBit.py to CORBA.py could be provide for people who don't
>care.  After all this is standard CORBA, if I don't use e.g.
>omniINSPOA, why should I care?
>
>Cheers!
>
>See Debian bug report:
>http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=202205
>  
>
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.

James.

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