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.
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