Migration python 3

Pourquoi ce n'est pas encore le cas ?

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

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.

Édité par firm1

Staff

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 !

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0
Staff

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).

Édité par SpaceFox

Staff
Auteur du sujet

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.

gustavi

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

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

gustavi

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 ?

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

gustavi

C'est déjà le cas.

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

gustavi

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.

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.

SpaceFox

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

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.

SpaceFox

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

Très honnêtement je ne vois pas ce que ça nous apporterait de gérer la double compatibilité.

SpaceFox

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

Staff

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.

+3 -0
Staff

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.

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+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

"I also don't trust Caribou anymore." — Joss Whedon

+0 -0
Staff

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 ?

Édité par gustavi

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0

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

gustavi

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 !

Médicament flemmard aux pul(p)sions imprécises. “Don’t wait for the perfect moment. Take the moment and make it perfect.”

+0 -0
Staff

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 ;)

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0

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

"I also don't trust Caribou anymore." — Joss Whedon

+0 -0
Staff
Auteur du sujet

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 front1) 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.

Pendant mes tests, je me suis aperçu aussi que le code est compatible python 3.3, j'ignore s'il faudrait gérer la compatibilité des autres versions 3.x. Si vous avez des avis.

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.

C'est l'occasion de passer sur des serveurs plus intéressant ?

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.


  1. A noter que si la PR de génération du front est mergée, les pures back n'auront même pas besoin de faire quelque chose avec python2. 

Staff

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.

Staff
Auteur du sujet

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

SpaceFox

:) J'ai dis virtualenv, mais je pensais supervisor …

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

SpaceFox

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

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

SpaceFox

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

Staff

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.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte