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. 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 -- [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/FVA4ACELS4H5T2HVVB7NXRALNZHZBVH3/ -- 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/XS4UHUI2NI2MSTCZ7SGVAVZ3NHTAOMSC/
