Building python 2 and python 3 packages for Fedora
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
Il giorno mer 5 giu 2019 alle ore 17:19 Nir Soffer <nsoffer@redhat.com> ha scritto:
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
I'm totally in agreement with this, +100 let's build for a single python version per distribution and above mapping looks perfect to me.
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
-- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig> <https://redhat.com/summit>
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. 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. Best regards,
Thoughts?
Nir _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/FVA4ACELS4H5T2...
-- Didi
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
for Fedora.
The current build process create packages with the same name for both
When the packages are published to oVirt repository, the python 3
packages.
We can rename the packages properly (e.g. python2-xxx, python3-xxx) but
and typically breaks later in the code publishing the packages.
There is also the difficulty of building both python 2 and python 3
building python 3 packages python 2 and python 3. packages overwrite the python 2 this requires lot of work 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
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
participants (3)
-
Nir Soffer -
Sandro Bonazzola -
Yedidyah Bar David