search

zestedesavoir / zds-site

Cœur du projet technique de Zeste de Savoir
https://zestedesavoir.com
Other
268 stars 161 forks source link

passage à Python 3 ? #280

Closed cgabard closed 10 years ago

cgabard commented 10 years ago

Même si python 2.7 est encore maintenu, pour les MAJ de securité, la branche 2.x est clairement en fin de vie. Pour autant c'est celle que nous utilisons alors même que la branche 3 est production-ready.

Qu'est ce qui nous empeche de passer à Python 3 ? Django 1.5 est compatible, quid du reste des modules ?

Au passage ça nous éviterai peut etre des prob tels que l'issue #54 puisque unicode deviens le type de chaine par defaut, et quasi unique, de python.

SpaceFox commented 10 years ago

Il faudrait aussi passer en Django 1.6 pour le support officiel "stable" de Python 3. Le 7 avr. 2014 09:35, "Christophe Gabard" notifications@github.com a écrit :

Même si python 2.7 est encore maintenu, pour les MAJ de securité, la branche 2.x est clairement en fin de vie. Pour autant c'est celle que nous utilisons alors même que la branche 3 est production-ready.

Qu'est ce qui nous empeche de passer à Python 3 ? Django 1.5 est compatible, quid du reste des modules ?

Au passage ça nous éviterai peut etre des prob tels que l'issue #54https://github.com/Taluu/ZesteDeSavoir/issues/54puisque unicode deviens le type de chaine par defaut, et quasi unique, de python.

Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/280 .

Alex-D commented 10 years ago

Je ne touche pas trop au back-end, mais je suis favorable à cette évolution. Par contre il faut voir si c'est jouable sans tout casser comme tu le précise.

firm1 commented 10 years ago

Je viens de générer à partir de notre requirements.txt la liste des lib incompatibles python 3. La voici.

Je pense qu'il vaut mieux d'abord envisager la migration vers django 1.6 (qui demande dejà du boulot) avant la migration python3

Alex-D commented 10 years ago

Nettoyer le requirements.txt au passage serait bénéfique je pense :)

cgabard commented 10 years ago

Ok donc c'est pas plus simple. En effet il faut passer à Django 1.6 avant, je vais faire une issue dédié.

cgabard commented 10 years ago

Je viens de générer à partir de notre requirements.txt la liste des lib incompatibles python 3. La voici.

  • async (which is blocking gitdb, which is blocking gitpython)
  • crispy-forms-foundation (inutilisée)
  • django-email-obfuscator
  • django-filter
  • django-oauth2-provider (inutilisée encore)
  • django-rest-swagger(inutilisée encore)
  • factory-boy

Je ne sais pas comment tu a généré ta liste mais elle semble se baser sur pip pour ça. Et elle semble supposer que si aucune version est indiqué c'est qu'elle ne passe pas. Or par exemple :

reste donc les dépendances de gitpyhon + les libres inutilisés (donc on s'en fout).

Concernant gitpython j'envisage de régler le prob en le remplaçant purement et simplement par Pygit2. Pourquoi ?

Et accesoirement cela me permetrat d'aller toucher au code de zds ailleurs que dans le markdown.

des objections ?

firm1 commented 10 years ago

Je ne sais pas comment tu a généré ta liste mais elle semble se baser sur pip pour ça.

ma liste viens de là elle se base bien sur pip et il faut renseigner le possibilité python3 sinon elle considère que c'est pas compatible.

Pygit2 n'a pas de dépendances autre que libgit2 qui est du C ansi qui compile partout (même sur smatphone)

Ce point précisément m'interpelle. Le truc avec les biding C, c'est qu'il faut que ça compile, et par expérience, t'as souvent un f*cking environnement ou ça ne compile pas, a cause de je ne sais quelle version de gcc ou du nombre de bits de ton OS (merci PIL).

Faudrait faire un POC sur cette lib sur différent OS avant de prendre une décision. Car si on veut partir sur une nouvelle lib, autant choisir une qui sera moins contraignante et efficace.

cgabard commented 10 years ago

Ce point précisément m'interpelle. Le truc avec les biding C, c'est qu'il faut que ça compile, et par expérience, t'as souvent un f*cking environnement ou ça ne compile pas, a cause de je ne sais quelle version de gcc ou du nombre de bits de ton OS (merci PIL).

Selon le site officiel :

libgit2 is a portable, pure C implementation of the Git core methods

et :

100% Cross-Platform : Linux, FreeBSD, OpenBSD, Mac OS X, iOS, Amiga, MinGW and fully native Windows.

et:

Zero Dependencies : Builds out of the box with no dependencies. Works in embedded devices and iOS.

et :

C89 Written with portability in mind. Builds in GCC, Clang and MSVC.

En fait libgit2 est plus portable que git lui même visiblement, qui est une dépendance de gitpython mais pas de libgit2 !

Je te ferait un POC via une PR, et tu testera !

firm1 commented 10 years ago

De ce que je vois de la doc de la lib en tout cas ça m'a l'air de ressembler pas mal à gitpython dans les fonctions utilisées, donc ça ne devrait pas être horrible à transcrire.

Je profite de cette issue donc pour noter toutes les fonctions critiques à traduire pour migrer vers Pygit2

je pense que la dernière fonction (get_blob) est un bon exercice pour un POC rapide.

cgabard commented 10 years ago

Je vais voir.

Accessoirement, git eux-même semblent vouloir migrer en partie sur libgit2 si on se fit à leurs Google-SOC : http://git.github.io/SoC-2014-Ideas.html

cgabard commented 10 years ago

Bon je confirme, dixit la mailling list ils ont très clairement l'intention d'utiliser libgit2 comme core-lib pour git lui même. Donc utiliser le port python officiel de cette lib me semble le mieux.

Je vais tenter de faire un POC et on fera une issue dédié à ce sujet en fonction du resultat.

Coy0te commented 10 years ago

Merci père noël ! :)

SpaceFox commented 10 years ago

Par pure curiosité, j'ai passé un coup de 2to3 sur le projet (je ne sais pas ce que ça vaut), c'est principalement des "u" devant les chaines qui sautent, et des imports réorganisés. Par contre ça touche quasiment tous les fichiers.

Y'a cette doc qui a l'air intéressante : http://www.diveintopython3.net/porting-code-to-python-3-with-2to3.html

cgabard commented 10 years ago

Évidemment qu'il va y avoir deux trois changements à envisager. Le passage en tout-unicode est probablement le plus impactant pour notre code qui manipule beaucoup des chaines de caractères. Il va faloir faire attention. Pour le reste c'est beaucoup plus simple. L'histoire des import doit être liés aux imports relatifs (on est un package). Peut être aura t'on quelques petites modifs liés aux fonctions qui renvoient des iterateurs à la place des listes. Mais dans l'ensemble, ça devrait aller vite, si toutes nos dépendances sont compatibles.

cgabard commented 10 years ago

(le plus gros changement a été dans l'API C qui a été toute cassé et donc ne nous implique pas directement)

SpaceFox commented 10 years ago

Bon, je me lance déjà dans le changement de lib git.

SpaceFox commented 10 years ago

Bon, si quelqu'un a envie de se pencher aussi sur PyGit2...

À moins d'avoir loupé un truc énorme (ce qui reste possible : vérifiez !), j'ai tiré les conclusions suivantes de mes recherches de ce soir :

Bref, LibGit2 ça a l'air excellent en théorie. Maintenant si ce n'est packagé nulle part, ce n'est tout simplement pas utilisable :S

SpaceFox commented 10 years ago

En fait je me demande si on ne devrait pas carrément faire appel à un Git installé sur l'OS (un genre de exec('git bla bla')... OK, c'est moche mais ça marche. Et c'est pas en version 0.xyz.

cgabard commented 10 years ago

Je ne suis pas persuadé. Ça demande de refaire des fonctions pour encapsulé tout ça et donc refaire gitpython. Du coup autant rester sur le truc actuel qui fonctionne, non ? Le 12 avr. 2014 00:52, "SpaceFox" notifications@github.com a écrit :

En fait je me demande si on ne devrait pas carrément faire appel à un Git installé sur l'OS (un genre de exec('git bla bla')... OK, c'est moche mais ça marche. Et c'est pas en version 0.xyz.

Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/280#issuecomment-40260944 .

SpaceFox commented 10 years ago

C'est pas faux...

Du coup, cette issue est en attente de l'un des évènements suivants :

firm1 commented 10 years ago

En attendant, GitPython est bloqué en python 2 a cause de async. Le module m'a l'air assez léger, je peux m'occuper de faire un update de async en python3 si tout zds est déjà traduit (ça c'est plus difficile).

cgabard commented 10 years ago

Bon le support de python 2.x vient d'être prolongé de 5 ans et ne s'arretera pas en 2015 comme annoncé precedement. En parralèle ils vont a priori combler des failles de secu présente dans cette branche. La migration n'est donc pas si urgente...

cgabard commented 10 years ago

Je ferme cette issue qui n'a plus lieu d'etre. On en re-discutera en temps voulu.

gustavi commented 9 years ago

Je pense qu'on peut ré-ouvrir cette issue. Je suis en train de faire des tests avec python 3 et seules 2 dépendances n'ont pas voulues s'installer (python-memcached et GitPython). J'ai pas tester le fonctionnement des autres mais vu le nombre de problème qu'on a avec l'utf8 et autre, passer à python3 (ce qui sera nécessaire un jour) est pour moi une bonne idée. Surtout que Django depuis la 1.5 supporte plutôt bien python 3 (j'ai 2 projets qui tourne en 1.6/1.7 avec python3 et aucun problème).

SpaceFox commented 9 years ago

Le connecteur MySQL est compatible Python 3 maintenant ? Le 28 oct. 2014 12:27, "Laville Augustin" notifications@github.com a écrit :

Je pense qu'on peut ré-ouvrir cette issue. Je suis en train de faire des tests avec python 3 et seules 2 dépendances n'ont pas voulues s'installer (python-memcached et GitPython). J'ai pas tester le fonctionnement des autres mais vu le nombre de problème qu'on a avec l'utf8 et autre, passer à python3 (ce qui sera nécessaire un jour) est pour moi une bonne idée. Surtout que Django depuis la 1.5 supporte plutôt bien python 3 (j'ai 2 projets qui tourne en 1.6/1.7 avec python3 et aucun problème).

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/280#issuecomment-60741685 .

cgabard commented 9 years ago

Alors, techniquement nos extensions de python-markdown ne le sont pas mais :

1- Ça peut etre fait vite 2- vu le travail a faire pour passer, on utilisera probablement pandoc d'ici là

Pour GitPython, le mieux serait qu'on profite de la refonte du module de tuto/article pour utiliser libgit2. Ça va nous obliger a fournir une version compilé de la lib pour les windowsiens mais c'est le moment de le faire. GitPython n'est plus maintenu, on est obligé de le patché manuellement et libgit2 est même utilisé par Git lui même.

Il faudrait donc le rajouter aux contraintes des zeps lié

gustavi commented 9 years ago

@SpaceFox ça dépend ce que tu utilises mais : https://docs.djangoproject.com/en/dev/ref/databases/#mysql-db-api-drivers .

Je suis en train de tester plus en détail les dépendances qui foirent lors de l'exécution du code. Pour memcached j'ai trouvé un fork compatible python3 mais aucune activité depuis 2 ans : https://pypi.python.org/pypi/python3-memcached/ .

firm1 commented 9 years ago

Boarf, je ne suis toujours pas convaincu de l'urgence de passer a python 3.

Si c'est juste pour une question d'utf8 on peut déjà les corriger en passant toutes les chaines a "u".

Pour le long terme oui il faudra passer a python3 mais uniquement sur le long terme selon moi.

cgabard commented 9 years ago

2014-10-28 12:36 GMT+01:00 firm1 notifications@github.com:

Si c'est juste pour une question d'utf8 on peut déjà les corriger en passant toutes les chaines a "u".

Ou simplement ajouter from __future__ import unicode_literals en haut des fichiers

Christophe.

cgabard commented 9 years ago

BTW je maintient que le passage a libgit2 est une bonne idée

Christophe.

2014-10-28 13:11 GMT+01:00 Christophe Gabard christophe.gabard@gmail.com:

2014-10-28 12:36 GMT+01:00 firm1 notifications@github.com:

Si c'est juste pour une question d'utf8 on peut déjà les corriger en passant toutes les chaines a "u".

Ou simplement ajouter from __future__ import unicode_literals en haut des fichiers

Christophe.

SpaceFox commented 9 years ago

Pour memcached j'utilise pylibmc mais je ne sais pas s'il est compatible python 3.

Sinon je plusseoie @firm1 : pour moi il n'y a pas d'urgence à passer à Python 3 (surtout avec un problème de dépendance tel que GitPython, qui est tout le socle du site) mais plutôt à mettre ceci en application : http://sametmax.com/lencoding-en-python-une-bonne-fois-pour-toute/

Le 28 octobre 2014 12:36, firm1 notifications@github.com a écrit :

Boarf, je ne suis toujours pas convaincu de l'urgence de passer a python 3.

Si c'est juste pour une question d'utf8 on peut déjà les corriger en passant toutes les chaines a "u".

Pour le long terme oui il faudra passer a python3 mais uniquement sur le long terme selon moi.

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/280#issuecomment-60742540 .

gustavi commented 9 years ago

Alors je propose de mettre un from __future__ import unicode_literals dans chaque fichier pour fixer le problème et ne pas à avoir à virer le u' ... ' lors du passage à python3. En même temps il faudrait virer les u' ... '.

Eskimon commented 9 years ago

Le truc cool c'est qu'une bonne regex ca peut virer tout les u'...' et les u"..."

Il y a une raison pythonesque de pourquoi le from machin etait pas utilise plus tot ?

SpaceFox commented 9 years ago

Il y a une raison pythonesque de pourquoi le from machin etait pas utilise plus tot ?

Je penche pour une méconnaissance

2014-10-28 13:33 GMT+01:00 Eskimon notifications@github.com:

Le truc cool c'est qu'une bonne regex ca peut virer tout les u'...' et les u"..."

Il y a une raison pythonesque de pourquoi le from machin etait pas utilise plus tot ?

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/280#issuecomment-60747934 .

firm1 commented 9 years ago

Il y'a aussi et "surtout" les effets de bords qui vont avec.

Ce n'est pas anodin comme modifications Le 28 oct. 2014 13:34, "SpaceFox" notifications@github.com a écrit :

Il y a une raison pythonesque de pourquoi le from machin etait pas utilise plus tot ?

Je penche pour une méconnaissance

2014-10-28 13:33 GMT+01:00 Eskimon notifications@github.com:

Le truc cool c'est qu'une bonne regex ca peut virer tout les u'...' et les u"..."

Il y a une raison pythonesque de pourquoi le from machin etait pas utilise plus tot ?

— Reply to this email directly or view it on GitHub < https://github.com/zestedesavoir/zds-site/issues/280#issuecomment-60747934>

.

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/280#issuecomment-60748067 .

gustavi commented 9 years ago

Je vais fixer tout ça alors.

SpaceFox commented 9 years ago

Il y'a aussi et "surtout" les effets de bords qui vont avec.

Ce n'est pas anodin comme modifications

Par exemple ?

cgabard commented 9 years ago

Le truc cool c'est qu'une bonne regex ca peut virer tout les u'...' et les u"..."

Pas besoin regex, le script 2to3 fournit par python s'en occupe tres bien.

Il y a une raison pythonesque de pourquoi le from machin etait pas utilise plus tot ?

Yep, le principal soucis est qu'il va être compliqué d'utilisé une chaine ascii. En gros ça passe tout en unicode. C'est tres bien si tout est en unicode, si certains morceaux de codes ne fonctionnent qu'avec des chaines Ascii brut, ça risque de casser. Mais a la limite c'est un mal pour un bien car ça veut dire que ça petera au passage a python 3

cgabard commented 9 years ago

A noter qu'il existe des libs, tel que six utilisé entre autre par Django, qui permettent de faciliter la transition en proposition des éléments au comportement commun entre les deux versions. Ce qui permet de produire du code compatible 2 et 3

firm1 commented 9 years ago

Par exemple ?

Toutes les chaines ingurgitées par gitpython et aussi python-markdon. Le 28 oct. 2014 13:45, "SpaceFox" notifications@github.com a écrit :

Il y'a aussi et "surtout" les effets de bords qui vont avec.

Ce n'est pas anodin comme modifications

Par exemple ?

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/280#issuecomment-60749164 .

gustavi commented 9 years ago

Donc on part sur quoi ? On fixe avec from __future__ import unicode_literals ou des u de partout ?

firm1 commented 9 years ago

Moi perso je préfère la solution à coup de u"..." qu'on pourra virer tout d'un coup le jour ou l'on migrera.

firm1 commented 9 years ago

Bon ça fait 2 semaines que ça bouillone du coté du projet upstream concernant GitPython.

Si j'en crois ce que je lis de leur coté depuis 1 semaine, GitPython devrait être rapidement compatible python3.

cgabard commented 9 years ago

Il n'en reste pas moins que passer à libgit2 serait probablement une meilleur idée sur le long terme.

On Mon Nov 17 2014 at 16:48:49 firm1 notifications@github.com wrote:

Bon ça fait 2 semaines que ça bouillone du coté du projet upstream concernant GitPython.

Si j'en crois ce que je lis de leur coté depuis 1 semaine, GitPython devrait être rapidement compatible python3.

— Reply to this email directly or view it on GitHub https://github.com/zestedesavoir/zds-site/issues/280#issuecomment-63324332 .

firm1 commented 9 years ago

Yop on est bien d'accord.

firm1 commented 9 years ago

La bonne nouvell du jour : l'upstream de git-python est compatible python 3