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

[Sandro Mani]

On 04.08.2017 13:23, Duncan Grisby wrote:
> 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!
Many thanks for your detailed reply. I've implemented your suggestions 
[1], in short the result being:

omniORB-devel:
[...]
/usr/bin/omniidl #!/usr/bin/python3
/usr/bin/omniidlrun.py #!/usr/bin/python3
/usr/lib/python3.6/site-packages/omniidl/*
/usr/lib/python3.6/site-packages/omniidl_be/*
/usr/lib64/python3.6/site-packages/_omniidl.cpython-36m-x86_64-linux-gnu.so*

omniORBpy-devel:
[...]
/usr/lib/python3.6/site-packages/omniidl_be/python.py

Should be good?

Thanks
Sandro

[1] https://copr.fedorainfracloud.org/coprs/smani/omniORB/builds/