On Wed, Jun 12, 2019 at 1:59 AM Nir Soffer <nsoffer@redhat.com> wrote:
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 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