Migration python 3

Le projet ZdS tourne aujourd'hui avec python 2, alors que ça fait 6 ans que python 3 est sorti. ça serait une bonne chose de passer un jour sous python 3 quand même, surtout que la version 2 nous pose souvent des petits soucis d'encodage.

Il y a énormément d’intérêt à passer sous Python 3 (j'avoue avoir la flemme de tout détailler, et je ne trouve pas d'article qui en parle bien), mais il y a encore quelques dépendances qui nous tirent vers le bas.

Les dépendances Infra

• supervisor : utilisé uniquement en production, il permet de superviser certains process sur le serveur de prod (zds, solr, etc.). Il existe des alternatives bien-sur, comme systemd par exemple.
• Mysql-python : Le choix de MySQL en production avait été fait en toute connaissance de cause. Aujourd'hui on ne peut toujours pas passer à Python 3 si on reste sous Mysql, car son pilote ne fonctionne pas sous Python 3.
• Python Memcached : C'est le pilote qui permet d'interagir avec memcached. Il n'est pas compatible python 3, mais un fork existe uniquement pour python 3.

Dépendances back-end applicatif

• GitPython : La lib qui nous permet d'interagir proprement avec git, qui avait été forkée au début du projet, n'était pas compatible python3. Mais bonne nouvelle, elle est maintenant compatible, et une PR est en cours pour migrer sur l'upstream et donc devenir compatible python 3.
• Python-ZMarkdown : un fork du projet Python-Markdown qui rajoute les extensions dédiées au markdown du site. Ce sont les extensions qui ne sont pas compatibles python 3 dans ce cas.

Conclusion ?

Au vu des dépendances actuelles, on dirait qu'une migration vers python 3 n'arrivera pas de si tôt.

Une façon de procéder serait que le projet soit a la fois compatible python2 et python3. Les dépendances bloquantes actuelles étant purement Infra, il suffirait de laisser tourner le serveur sous python2.

Ce topic est là pour faire un petit état de l'art, et nous aider à orienter progressivement nos choix futurs, vers une migration python 3.

Tu confonds sentry (le serveur écrit en python 2 et qui le restera encore un moment (du moins c'est ce que m'avais dit un des dev lors d'une discussion il y a 6 mois) et donc qui est indépendant de ZdS) et raven qui est la lib client, elle compatible python 3.

Ensuite memcached et MySQL sont des faux problèmes étant donné qu'il y à des forks/alternarives compatibles.

Supervisor est assez simple à remplacé comme tu l'as dit.

Le dev de GitPython à repris et va devenir compatible py3k très rapidement (si ce n'est pas déjà le cas).

Donc où est le problème ? Pour moi ce n'est qu'une question de semaines !

Systemd nécessiterait de changer de version d'OS - donc à priori d'attendre la sortie de Debian 8 - ou tout simplement d'utiliser une alternative.

Sentry n'est pas une dépendance : ça n'impacte que le serveur Sentry, pas le projet surveillé. Raven, l'outil utilisé dans l'application pour envoyer les logs, est lui compatible Python 3.

mysql-python, le projet, est mort, que ce soit la version actuelle ou la théorique v2 future. On trouve des alternatives en particulier PyMySQL qui est celle qui revient le plus.

Memcached offre une solution de secours.

GitPython a une PR en cours pour être compatible Python 3.

La situation mérite d'être étudiée, mais est loin d'être aussi coincée que semble indiquer le post initial.

Une façon de procéder serait que le projet soit a la fois compatible python2 et python3. Les dépendances bloquantes actuelles étant purement Infra, il suffirait de laisser tourner le serveur sous python2.

Très honnêtement je ne vois pas ce que ça nous apporterait de gérer la double compatibilité. Si un fork en a besoin et nous propose une PR, je l'accepterai avec joie ; par contre on a 218 issues ouvertes internes qui me paraissent à peu près toutes plus importantes que de gérer une double compatibilité.

Notez que dans ces 218 on en a une qui parle explicitement de passer à python 3 (sans mentionner de double compatibilité, parce que c'est encore autre chose).

Possible, je ne sais pas comment tout ceci a été installé en prod, donc je peux me tromper.

Les forks de MySQL-python ne sont pas encore très stable dans mes souvenirs. Tu en a un sous la main de bonne qualité en python 3 ?

C'est déjà le cas.

Bah une questions de semaines, ça peut faire beaucoup de semaines .

Mais en plus sérieusement, c'est surtout parce qu'il y'a pas mal d'autres problèmes plus urgent à traiter qu'un passage à python 3 actuellement.

J'ai cité systemd, parce que c'est celui que j'ai en tête, mais il existe certainement d'autre alternatives.

J'aurai tendance à me referer aux alternatives proposées par Django pour les driver Mysql

Moi non plus, mais je me devais de proposer tout de même.

Perso je pense que la double compatibilité, c'est la merde. On a pas assez de dev déjà et il y a peu de forks (et donc peu de demande externe), je ne voit pas l'interet.

A noter au passage que notre markdown n'est pas 100% compatible. En fait les extensions ne le sont pas mais un membre a déjà fait la conversion donc ça pourrait être rapide.

Ah je l'avais oublié celui-là. Je le note dans le premier topic

Si tu peux en profiter pour virer Sente que la liste soit correcte.

Yop on est bon là je pense.

Au passage, en oubliant de passer dans mon venv et en voulant mettre npm à jour :

1
2
3
4
5

> node-gyp rebuild

gyp ERR! configure error 
gyp ERR! stack Error: Python executable "python" is v3.4.2, which is not supported by gyp
gyp ERR! stack You can pass the --python switch to point to Python >= v2.5.0 & < 3.0.0.

Pour ça, faut gueuler ici, du côté de Google, qui veut pas mettre à jour son outil gyp pour supporter Python 3…

Sinon, pour palier ce problème, il faut indiquer à node-gyp quelle version de python utiliser, via npm config set python /chemin/vers/python2

Migration en cours ! Pour suivre l'avancement : https://github.com/zestedesavoir/zds-site/issues/2272

Actuellement le plus gros problème est gyp qui est full python2 et ça ne risque pas de changer tout de suite.

Pour les dev front : à quoi ça sert ? Est-ce indispensable ? Peut-on le remplacer ?

Oui enfin GYP c'est un outils, c'est pas vraiment genant. On ne l'importe pas directement, non ?

C'est comme mon IDE, qu'il soit codé en Python2 on s'en fout un peu.

Oui oui, il faut juste build le front avec un environnement python2.

En fait, ce n'est pas un dépendance directe mais certaines de nos dépendances doivent l'utiliser. D'ailleurs, npm l'utilise donc on ne peut pas faire autrement que passer par la méthode de Sandhose. En soit ce n'est pas très gênant, il suffit de le mettre dans la documentation et d'envoyer un message privé aux développeurs lors du passage à python 3 !

Merci de ta réponse ! Vu qu'il va falloir refaire le venv, tout le monde va devoir se replonger dans la doc d'installation

Bah, si c'est aussi facile qu'aujourd'hui ça va (en admettant une connexion digne de ce nom, parce qu'il commence à prendre du gras ce projet).

Il suffit juste de dire à npm où se trouve python2 via la commande npm config set python /path/to/executable/python2.7. C'est à faire qu'une seule fois, et c'est nécessaire que si python2 n'est pas l’exécutable par défaut pour python

Bon, la migration vers python est plus proche que jamais. La PR est en cours. J'aimerai profiter de ce topic pour discuter un peu des changements que ça va nous apporter et j'ai besoin de vos avis sur une question importante.

La version de python

Comme on l'a évoqué plus haut dans ce topic, une de nos dépendances npm n'est pas compatible python3, il s'agit de node-gyp. Pour développer, il sera donc nécessaire d'avoir python2 (si vous faites du front¹) et python3 installé chez vous.

C'est bien ce qui est fait dans la PR qui, via tox, permet de gérer les deux environnements (front et back) avec deux version de python a dispo.

En gros, le back-end (django et ses enfants) passe en python3.4.

L'infrastructure

Nous tournons aujourd'hui sous debian, et python 3.4, debian ne connait pas. D'ou ma question ci-dessus car Debian connait au moins python 3.2. Si on veux rester exclusivement sous python 3.4 il va falloir changer d'OS. Lequel me direz-vous ? Et bah, bonne question.

En fonction du type d'infrastructure cible, on saura si on reste sur virtualenv ou si on va sur systemd.

Bonne question aussi. Étant donné que dans l'hypothèse ou on migre d'OS (cf. encore ma question du dessus) on va refaire toutes les installs (prod, préprod), je pense que c'est une bonne idée de le faire sur des nouveaux serveurs tout neufs. Si c'est le cas, il faudra voir avec l'association et préparer la migration d'infra.

Vous l'aurez compris, la question du haut (compatibilité sur toutes les 3.x), implique beaucoup de choses. N'hésitez pas à donner votre avis.

Nous tournons aujourd'hui sous debian, et python 3.4, debian ne connait pas. D'ou ma question ci-dessus car Debian connait au moins python 3.2.

Debian 7 (version actuelle) connaît Python 3.2. Debian 8 qui sort dans 10 jours connaît python 3.4.

on saura si on reste sur virtualenv ou si on va sur systemd.

Cette phrase n'a aucun sens : virtualenv et systemd n'ont aucun rapport.

Systemd, par contre, remplace supervisor.

Pour moi il n'y a même pas de question à se poser : on a là un excellent prétexe pour prendre des serveurs un peu moins aléatoires, surtout qu'à priori les actuels vont devenir plus chers un de ces 4 (OVH faisant n'importe quoi).

Donc, mon avis est : profitons du passage à Python 3 pour se prendre une meilleure offre et y coller une Debian 8.

J'ai dis virtualenv, mais je pensais supervisor …

Ah ben super nouvelle. On a même pas besoin de se poser la question dans ces conditions.

J'approuve. Du coup, a voir avec l'association non ?

Python 3.3 est vieux et python 3.2 c'est encore pire. Normalement on devrait pas avoir de mal a supporter 3.3 et 3.4 a la fois mais c'est inutile a mon sens. Autant se baser sur la 3.4 qui va etre maintenu encore pas mal de temps. D'autant que la 3.5 va arriver d'ici 6 mois, autant éviter de prendre trop de retard.