Migrando a python 3 en Debian Stretch

Que aún no haya salido Debian 8.0 Jessie no significa que no sea tiempo de empezar a pensar y planificar más allá. Es más, en mi opinión es el tiempo apropiado. Y eso es precisamente lo que han hecho los debianitas pythonistas que se han reunido en la PyCon, y cuyas conclusiones se resumen en el siguiente mensaje enviado a debian-devel-announce: Python 2, Python 3, Stretch & Buster:

Python 2 is scheduled to be EOL'd upstream officially and for good in 2020. We're in 2015 now (wow, that went quickly), and keeping our release cadence up (3 years a pop) puts Stretch up in 2018, and Buster in 2021.

Short of a brilliant Stretch cycle, this should be basically rightish. after Python 2 is EOL -- that's right, EOL! Nuts, right?

A continuación esbozan un plan para acometer la migración de Debian a python 3, empezando por la numerosa infraestructura de la propia Debian escrita en python 2.

The idea is to basically stop uploading new Python 2 only libraries, port things on the critical path, and swap leaf packages to Python 3.

Y, claro, piden colaboraciones:

I plan on creating a Python 3 porting team. It'll have a fancy buzzword name, but I'm a bit too tired to think of one now. Such a porting team would consist of folks who are here to help port things important to us (Debian) to Python 3 so that we can get off of Python 2 for Buster.

Lo que no veo tan claro es que tengan 2 ciclos de release completos (Debian Stretch y el posterior Debian Buster) para desembarazarse de python 2. Según mis cálculos, Debian Stretch ya no debería llevar los paquetes de python 2 (y por lo tanto ninguna dependencia), porque el intérprete quedaría sin mantenimiento ni parches críticos de seguridad durante una versión estable de Debian, concretamente en la ventana entre 2020 y el lanzamiento de Buster. A mi me parece que la cadencia entre releases es más bien de dos años y medio que tres, pero aun así es muy apurado y arriesgado marcarse 2020 como la fecha inamovible de aparición de Buster, estas cosas tienen que ser flexibles por lo que pudiera pasar.

El problema de planificacion, graficamente

Y ya de períodos de duración de una LTS ni hablamos. Cualquier distribución que por ejemplo quiera dar 5 años de mantenimiento garantizado y que incluya python 2 tiene que salir como muy tarde este año 2015. Cualquier cosa LTS a partir de 2016 se va a encontrar con que van a tener que mantener python 2 ellos mismos, y además en contra de la voluntad de los propios desarrolladores upstream de python, que si se han marcado precisamente un límite a no cruzar es porque quieren acabar con la dualidad entre las versiones 2 y 3 de una vez, que tanto les está perjudicando. Cualquier mantenimiento posterior a esa fecha es un desafío directo a su decisión, ya que prolongaría de facto la situación, y por lo tanto no le van a dar soporte desde el propio proyecto.

Así que, o planificas para quitarte de python 2 para 2020, o ve preparando la cartera para contratar programadores que te hagan el trabajo que upstream no te va a hacer. Algo que, por ejemplo Red Hat o Canonical se pueden permitir en un momento dado, pero ¿el resto? ¿Los proyectos de voluntarios como Debian? Yo diría que no. Y si quieren quitarse dolores de cabeza en el futuro, más vale que empiecen a pensar en deshacerse totalmente de python 2 en Stretch, no en Buster.

:wq

blogroll

social