Nettoyage des dépendances

[SpaceFox]

La liste des requirements me paraît bien longue et ça met super longtemps à s'installer. Or, j'ai l'impression qu'il y a un certain nombre de dépendances à ZdS qu'on n'utilise pas ou plus.

J'ai donc fait un état des lieux en regardant dans tous les fichiers *.py *.html *.json *.txt du projet, voir si on avait une référence (requirements.txt exclus). Les résultats sont les suivants :

Ce qui est d'évidence utile

En prod

• django>=1.6,<1.7 : OK
• django-haystack : OK
• django-model-utils : OK
• python-memcached : OK
• lxml : OK
• south : OK. Deviendra inutile au passage à Django 1.7
• easy-thumbnails : OK
• https://github.com/zestedesavoir/GitPython/archive/0.3.2-RC1.z2.zip : OK
• https://github.com/zestedesavoir/Python-ZMarkdown/archive/2.4.1-zds.9.zip : OK
• pillow : OK d'une manière curieuse : il ne sert plus qu'à convertir des .gif en .png

En prod, avec une question

• django-crispy-forms==1.3.2 : OK. Une raison pour avoir fixé la version ?
• django-email-obfuscator==0.1.2 : OK. Une raison pour avoir fixé la version ?
• django-munin==0.1.4 : OK. Une raison pour avoir fixé la version ?
• pygeoip==0.3.1 : OK. Une raison pour avoir fixé la version ?
• factory-boy==2.2.1 : OK à priori (pas 100% sûr). Une raison pour avoir fixé la version ?
• pygal : OK, mais pour un graphe qui n'est plus visible en front --> à garder ?

En développement uniquement

• django-debug-toolbar : OK (outil de dev)
• flake8 : OK (outil de dev)
• autopep8 : OK (outil de dev)

Ce qu'on peut supprimer dès maintenant

• django-discover-runner==0.4 : Inutile depuis qu'on a Django 1.6 puisqu'intégré à ce dernier

Ce qui semble inutile

Attention, les dépendances listées ici sont peut-être utiles d'une manière détournée ! Il faut vérifier chacune d'elles !

Hypothétiques dépendances d'outils ne déclarant pas leurs dépendances

Ceux-ci sont peut-être nécessaires parce qu'ils sont requis par une autre dépendance, qui ne peut pas les requérir explicitement. Je dis peut-être une énorme connerie, à vérifier avec le fonctionnement de pip.

• pygments : Aucune référence, je suppose que maintenant c'est une dépendance de "Python-ZMarkdown" et plus de zds-site.
• pysolr : Aucune référence. Doublon avec Haystack / dépendance de ce dernier ?

Semble servir pour une API qu'on a pas aujourd'hui

• django-oauth2-provider : Aucune référence
• djangorestframework : Aucune référence
• django-rest-swagger : Aucune référence

Aucune référence évidente

• bleach==1.2.2 : Aucune référence
• coverage==3.7.1 : Aucune référence
• pytz==2013d : Aucune référence
• PyYAML==3.10 : Aucune référence
• defusedxml : Aucune référence
• django-dynamic-fixture : Aucune référence
• django-simple-captcha : Aucune référence mis à part un chargement des URLs
• django-filter : Aucune référence
• django-guardian : Aucune référence
• httplib2 : Aucune référence

[firm1]

Une piste simple et rapide.

Lancer les batteries de tests sur un environnement a nu. Si ça crache, rajouter la dépendance manquante jusqu'à ce que ça ne crache plus.

[SpaceFox]

Je trouve ça un peu flippant d'avoir des dépendances qu'on est obligés de tester pour savoir si elles sont nécessaires >_< M'enfin au moins comme ça on sera fixés.

Pour les numéros de version forcés, une idée ? Idem pour la lib qui sert à générer un graphe invisible ?

[cgabard]

pygments : Aucune référence, je suppose que maintenant c'est une dépendance de "Python-ZMarkdown" et plus de zds-site.

En effet c'est une dépendance du markdown MAIS c'est une dépendance optionnel techniquement (il l'utilise pour faire la coloration si present). Je peux peut être l'ajouter comme dépendance dur mais ça me semble pas forcément évident.

[SpaceFox]

OK, on peut la laisser.

On peut mettre des commentaires dans ce fichier ?

Le 14 août 2014 13:25, Christophe Gabard notifications@github.com a écrit
:

pygments : Aucune référence, je suppose que maintenant c'est une
dépendance de "Python-ZMarkdown" et plus de zds-site.

En effet c'est une dépendance du markdown MAIS c'est une dépendance
optionnel techniquement (il l'utilise pour faire la coloration si present).
Je peux peut être l'ajouter comme dépendance dur mais ça me semble pas
forcément évident.

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[gustavi]

Pour les numéros de version forcés, une idée ?

Je pense que ça vient d'un pip freeze. Des fois c'est utile quand une nouvelle version change un peu trop ou qu'une ancienne version n'est plus compatble.

[firm1]

Mon analyse des requirements.

A conserver :

• django>=1.6,<1.7
• bleach==1.2.2
• pygments
• coverage==3.7.1
• south
• pytz==2013d (utile pour calculer les dates git)
• django-crispy-forms==1.3.2
• django-email-obfuscator==0.1.2
• django-debug-toolbar
• django-haystack
• django-model-utils
• django-munin==0.1.4
• python-memcached
• lxml
• pygal
• httplib2
• pysolr
• factory-boy==2.2.1
• pygeoip==0.3.1
• pillow
• https://github.com/zestedesavoir/GitPython/archive/0.3.2-RC1.z2.zip
• https://github.com/zestedesavoir/Python-ZMarkdown/archive/2.4.1-zds.9.zip
• flake8
• autopep8
• easy-thumbnails

Utiles dans l'avenir mais on peut les virer aujourd'hui

• PyYAML==3.10 (pour une API)
• djangorestframework
• django-filter
• django-rest-swagger
• django-oauth2-provider
• defusedxml
• django-guardian

A virer

• django-dynamic-fixture
• django-simple-captcha
• django-discover-runner==0.4

NB : Les versions sur certains packages sont fixés pour être certain de la stabilité du module, à un instant donné. On ne va pas s'amuser à surveiller nos dépendances tous les matins pour s'assurer que le projet ne plante pas avec la dernière mise à jour d'un module.
Si on veut faire évoluer la version de dépendances, ça doit passer par une QA, comme n'importe quelle évolution.

[SpaceFox]

• Les dépendances "utiles dans l'avenir" sont à dégager, elles reviendront quand on en aura besoin, si jamais un jour on en a besoin.
• A quoi servent toutes les dépendances qui n'ont pas de références mais que tu déclares quand même comme nécessaires ?
  • pygments : OK, pour avoir la coloration (dépendance facultative de python-markdown)
  • bleach ?
  • coverage ?
  • pytz : OK, mais qui fait ce calcul ? Si c'est ZdS, comment on peut avoir besoin de cette dépendance sans jamais l'appeler ? Un genre de classloader mais en Python ?
  • httplib2 ?
  • pygal ? Utile uniquement si on affiche le graphe. Soit on affiche le graphe et on la garde, soit on la benne et le graphe invisible avec.
  • pysolr ?
• J'entends bien l'argument de fixer les numéros de versions pour être certains de la stabilité du module. Mais dans ce cas, pourquoi ce n'est fait que sur certains modules et pas tous ?

[firm1]

Je sais plus il faut lire le code, y'a des modules qui ont peut être perdu
de l'intérêt suites aux modifications depuis (j'ai pas tout suivi) d'où mon
premier message : "on procède par élimination" ça sera toujours plus rapide
et efficace.

Pour pygal, si je me souviens bien, on a une issue régression sur les
graphes dans le profil. Donc on ne va pas virer les fonctionnalités back
qui ne sont pas encore implémentée en front.

Mais dans ce cas, pourquoi ce n'est fait que sur certains modules et pas
tous ?

Parce que personne ne s'en ait inquiète jusque là ;)

Mais globalement pour corriger cette issue il y'a pas de magie, on lit le
code et on vire ce qui n'intervient pas dans le code.
Le 14 août 2014 14:52, "SpaceFox" notifications@github.com a écrit :

• Les dépendances "utiles dans l'avenir" sont à dégager, elles
  reviendront quand on en aura besoin, si jamais un jour on en a besoin.
• A quoi servent toutes les dépendances qui n'ont pas de références
  mais que tu déclares quand même comme nécessaires ?
  • pygments : OK, pour avoir la coloration (dépendance facultative
    de python-markdown)
  • bleach ?
  • coverage ?
  • pytz : OK, mais qui fait ce calcul ? Si c'est ZdS, comment on
    peut avoir besoin de cette dépendance sans jamais l'appeler ? Un genre de
    classloader mais en Python ?
  • httplib2 ?
  • pygal ? Utile uniquement si on affiche le graphe. Soit on affiche
    le graphe et on la garde, soit on la benne et le graphe invisible avec.
  • pysolr ?
    • J'entends bien l'argument de fixer les numéros de versions pour
      être certains de la stabilité du module. Mais dans ce cas, pourquoi ce
      n'est fait que sur certains modules et pas tous ?

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[SpaceFox]

Mais globalement pour corriger cette issue il y'a pas de magie, on lit le code et on vire ce qui n'intervient pas dans le code.

Donc, sauf magie de Python, on vire tout ce que j'ai dit qu'il était inutile d'avoir.

[SpaceFox]

Voilà une bonne chose de faite !