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.

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

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.

Thoughts? Nir _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FVA4ACELS4H...

On Thu, Jun 6, 2019 at 9:10 AM Yedidyah Bar David <didi(a)redhat.com&gt; wrote: > > On Wed, Jun 5, 2019 at 6:21 PM Nir Soffer <nsoffer(a)redhat.com&gt; 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.