On Thu, Jun 6, 2019 at 9:10 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Wed, Jun 5, 2019 at 6:21 PM Nir Soffer <nsoffer@redhat.com> wrote:
In several projects (e.g. vdsm, imageio, sanlock), we have the issue of
for Fedora.
The current build process create packages with the same name for both
When the packages are published to oVirt repository, the python 3
packages.
We can rename the packages properly (e.g. python2-xxx, python3-xxx) but
and typically breaks later in the code publishing the packages.
There is also the difficulty of building both python 2 and python 3
building python 3 packages python 2 and python 3. packages overwrite the python 2 this requires lot of work packages from same spec in the same
build. This should be possible but not easy.
I agree about both, but we already have several projects that do exactly that, so we do have some experience.
Since python 2 is about to die soon, should we simplify by building
python 2 *or* python 3, depending
on version?
Fedora 29: python 2.7 Fedora 30: python 3.7 CentOS 7: python 2.7 CentOS 8: python 3.6
Generally speaking, this is the approach we took with stand-alone tools, e.g. ovirt-iso-uploader, ovirt-engine*setup*.
With libraries, we did package for both - e.g. otopi (not a pure library, but not a standalone tool either), ovirt-engine-lib.
This make it possible to test and develop on python 2.7 until vdsm is
fully functional on python 3,
and it save resources in the CI.
vdsm is similar to the (python code in the) engine, in that regard. Most of it is a set of standalone tools, but some parts are libraries, also used by external tools.
The only users of vdsm code are mom and hosted engine that can be used anyway on python 3 before vdsm will be compatible with python 3, so I don't see a reason to invest in this direction, and we also don't have capacity to do this anyway.
If you package the libraries for only a single version of python, you require all the 3rd-party tools to adapt their python support exactly at same cadence of vdsm. By providing libraries for both, at least for some time, you allow a smoother transition. If you want to avoid that, I guess it's best to enumerate the current users of vdsm library code, and coordinate with these. This includes hosted-engine*, but perhaps also others, not sure.
Good point, but we are 5 years late. This plan also works sanlock. We will release this week sanlock 3.8 for El 8.1 and Fedora 30 - only for python 3. I discussed this with Dan offline and he is happy with this plan. Nir