On Wed, Jun 12, 2019 at 1:59 AM Nir Soffer <nsoffer(a)redhat.com> wrote:
On Thu, Jun 6, 2019 at 9:10 AM Yedidyah Bar David <didi(a)redhat.com> wrote:
> On Wed, Jun 5, 2019 at 6:21 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
> > In several projects (e.g. vdsm, imageio, sanlock), we have the issue of building
python 3 packages
> > for Fedora.
> > The current build process create packages with the same name for both python 2
and python 3.
> > When the packages are published to oVirt repository, the python 3 packages
overwrite the python 2
> > packages.
> > We can rename the packages properly (e.g. python2-xxx, python3-xxx) but this
requires lot of work
> > and typically breaks later in the code publishing the packages.
> > There is also the difficulty of building both python 2 and python 3 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.
Fine for me as well.