Python 2 removal strategy
Hi, I am the maintainer of the "python-astropy" package, that currently creates packages for both Python 2 and Python 3. Both packages have a number of reverse dependencies. Recently, upstream announced a new version 3.0 of astropy, which supports Python 3 only, and I think of the best mid-term strategy: The old version 2.0 is supported upstream for ~2 years, and I want to have a smooth migration path. I checked the wiki, but could not find good information about migration. I thought of a temporary package split: create a new source package "astropy" that inherits of the current python-astropy package, but only builds python3-astropy (and the utils + doc, which depend on python3-astropy), and update this to version 3.0. Then I would remove these binary packages from the python-astropy package. In parallel, I would file bugs (severity: important) to remove the reverse dependencies of the Python 2 packages (many of them are mine, but also may have reverse dependencies). As long as there are substantial problems with the removal of the Python 2 support, I then keep the "old" python-astropy package updated. Once everything is figured out and we decide to finally kick out Python 2 support (from Debian-Astro, or from Debian), I would set the remaining bugs as RC, and (once they are solved) remove the "python-astropy" package. Does this sound reasonable? And how should I do this technically? Best regards Ole
PyQwt3D packaging strategy
Hi list I am updating my package pyqwt3d. It is tested for Qt5, python2 and python3. The changes were so huge that I made GitHub fork of it: https://github.com/GauiStori/PyQwt3D Now I have two questions: 1. Shall I skip the python2 version since it is already end of life? 2. Shall I make my changes into a huge patch (changes from upstream in the DPMT git repository) or make my own GitHub repository as an upstream source? Regards Gudjon
Re: Python 2 removal strategy
On 10.01.2018 17:06, Ole Streicher wrote: > Hi, > > I am the maintainer of the "python-astropy" package, that currently > creates packages for both Python 2 and Python 3. Both packages have a > number of reverse dependencies. > > Recently, upstream announced a new version 3.0 of astropy, which > supports Python 3 only, and I think of the best mid-term strategy: The > old version 2.0 is supported upstream for ~2 years, and I want to have a > smooth migration path. I checked the wiki, but could not find good > information about migration. Currently discussed. See "Python2 EOL and moving towards Python3" on this ML. > I thought of a temporary package split: create a new source package > "astropy" that inherits of the current python-astropy package, but only > builds python3-astropy (and the utils + doc, which depend on > python3-astropy), and update this to version 3.0. Then I would remove > these binary packages from the python-astropy package. In parallel, I > would file bugs (severity: important) to remove the reverse dependencies > of the Python 2 packages (many of them are mine, but also may have > reverse dependencies). > > As long as there are substantial problems with the removal of the Python > 2 support, I then keep the "old" python-astropy package updated. Once > everything is figured out and we decide to finally kick out Python 2 > support (from Debian-Astro, or from Debian), I would set the remaining > bugs as RC, and (once they are solved) remove the "python-astropy" > package. > > Does this sound reasonable? And how should I do this technically? well, astropy is not such a mainstream package that I would mind removing some of it's reverse dependencies. If you want to add the additional pain having a separate Python2 source stack, go for it. I wouldn't want to do that myself. If not, just go ahead with Python3 after having identified the reverse dependencies which are not maintained by yourself. Matthias
Re: Python 2 removal strategy
Hi Ole, It would be great have two different package. One of them, the python3 version and maintain the python2 version. Regards! Emmanuel El mié., 10 de ene. de 2018 a la(s) 18:03, Matthias Klose escribió: > On 10.01.2018 17:06, Ole Streicher wrote: > > Hi, > > > > I am the maintainer of the "python-astropy" package, that currently > > creates packages for both Python 2 and Python 3. Both packages have a > > number of reverse dependencies. > > > > Recently, upstream announced a new version 3.0 of astropy, which > > supports Python 3 only, and I think of the best mid-term strategy: The > > old version 2.0 is supported upstream for ~2 years, and I want to have a > > smooth migration path. I checked the wiki, but could not find good > > information about migration. > > Currently discussed. See "Python2 EOL and moving towards Python3" on this > ML. > > > I thought of a temporary package split: create a new source package > > "astropy" that inherits of the current python-astropy package, but only > > builds python3-astropy (and the utils + doc, which depend on > > python3-astropy), and update this to version 3.0. Then I would remove > > these binary packages from the python-astropy package. In parallel, I > > would file bugs (severity: important) to remove the reverse dependencies > > of the Python 2 packages (many of them are mine, but also may have > > reverse dependencies). > > > > As long as there are substantial problems with the removal of the Python > > 2 support, I then keep the "old" python-astropy package updated. Once > > everything is figured out and we decide to finally kick out Python 2 > > support (from Debian-Astro, or from Debian), I would set the remaining > > bugs as RC, and (once they are solved) remove the "python-astropy" > > package. > > > > Does this sound reasonable? And how should I do this technically? > > well, astropy is not such a mainstream package that I would mind removing > some > of it's reverse dependencies. If you want to add the additional pain > having a > separate Python2 source stack, go for it. I wouldn't want to do that > myself. If > not, just go ahead with Python3 after having identified the reverse > dependencies > which are not maintained by yourself. > > Matthias > > -- Arias Emmanuel https://www.linkedin.com/in/emmanuel-arias-437a6a8a http://eamanu.com
Re: Python 2 removal strategy
Hi Ole, > I thought of a temporary package split: create a new source package > "astropy" that inherits of the current python-astropy package, but only > builds python3-astropy (and the utils + doc, which depend on > python3-astropy), and update this to version 3.0. Then I would remove > these binary packages from the python-astropy package. In parallel, I > would file bugs (severity: important) to remove the reverse dependencies > of the Python 2 packages (many of them are mine, but also may have > reverse dependencies). This is more or less what I ended up doing for the plotting module PyX and I think it's a reasonable path forward given that there will also be lots of legacy user scripts out there that are using pyx (and astropy) that don't need to be broken just yet. The pyx source continues to build python-pyx and is stuck at the last version of pyx that supported Python 2. It's only used by users in their existing scripts for plotting their data and they will keep working for as long as we have a Python 2 interpreter. The only changes that happen in python-pyx are adjusting to new dependencies such as python-imaging → python-pil. An additional source package pyx3 builds python3-pyx and is tracking upstream releases meaning new features get added etc. pyx3 isn't a great source name but then users never see it and certainly never need to guess it. That said, pyx3 is probably less confusing as a name than astropy vs python-astropy. I've wondered about putting some noisy warnings into the python-pyx code that talks about the need to migrate to Python 3 if you want your scripts to keep working into the future. I've not done so because I assume that anyone using pyx probably pays attention to upstream documentation and knows this story already; at the risk of hijacking this thread, I'd be interested in the thoughts of others on this. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
