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: [EMAIL PROTECTED]
WWW:   http://www.daa.com.au/~james/



_______________________________________________
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Reply via email to