[omniORB] Side-by-side installation of python2 and python3 omniORB

[Duncan Grisby]

On Thu, 2017-08-03 at 17:05 +0200, Sandro Mani via omniORB-list wrote:

> I maintain the omniORB / omniORBpy packages for Fedora. Given the 
> ongoing transition to python3, I've been asked to also provide
> python3 packages for omniORB.

That's good.

> My issue is the name clashing of the
> 
> /usr/bin/omniidl
> /usr/bin/omniidlrun.py
> 
> scripts - all other python related files are installed underneath
> the respetive python site prefixes and hence don't cause any
> conflicts.
> 
> I take it is a bad idea to rename omniidl to say omniidl-3 because it
> is likely called by other scripts which expect omniidl to be named
> such.
> So I wonder whether side-by-side installation is even possible? Resp.
> does it actually matter which interpreter version is used to run 
> omniidl/omniidlrun.py?

It sort-of matters, and it sort-of doesn't.

omniidl uses a C++ extension module, and the Python source needs a few
changes between Python 2 and 3. It is therefore essential that
/usr/bin/omniidl has a first line #! that runs the correct matching
Python version.

However, omniidl itself behaves totally identically whether it is run
by Python 2 or Python 3. From that point of view, if /usr/bin/omniidl
used Python 3, but I wanted to write Python 2 code, it wouldn't matter
to me at all. When generating Python code with "omniidl -bpython", the
output is identical for every Python version.


What is the Fedora policy about preferred Python version?  Whatever the
preferred version, the C++ omniORB-devel package should build omniidl
against that version, and that will give you the /usr/bin/omniidl
script with corresponding #! line for the chosen Python. I see that in
FC 26 the omniORB-devel package uses Python 2.7, but maybe that should
switch to Python 3?

Either way, you can then easily have omniORBpy packages for both Python
versions that contain just the runtime libraries (both Python and C++),
which will install in the corresponding Python site-packages directory.

The only slightly awkward thing is omniidl_be/python.py, which is the
Python back-end for omniidl. That is required for developers using both
Python versions, but it must be installed in the site-packages
directory of the Python version used by /usr/bin/omniidl. I think the
easiest way to handle that is to have a separate omniORBpy-devel
package that is independent of omniORBpy Python version, and installs
omniidl_be/python.py in the right place to match /usr/bin/omniidl.


I hope that made sense!

Duncan.

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