On Wed, Jun 12, 2019 at 1:59 AM Nir Soffer <[email protected]> wrote: > > On Thu, Jun 6, 2019 at 9:10 AM Yedidyah Bar David <[email protected]> wrote: >> >> On Wed, Jun 5, 2019 at 6:21 PM Nir Soffer <[email protected]> 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.
OK >> >> 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. -- Didi _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/SQPILNMJL7LEHWG55WSLPYP3BSPOOK7V/
