Donner la possibilité d'utiliser des morceaux de zds ailleurs

J'ai eu besoin il y a un moment de monter un site sous dont le back-end choisi était Django. Comme la grosse majorité des sites, il me fallait un module de gestion des comptes utilisateurs (inscription/connexion/profil/etc.), ainsi qu'un module de gestion de la messagerie privée.

J'ai exploré django packages et autant le dire, je n'ai pas trouvé extacement ce que je voulais. Dans l'urgence, je me suis rabattu sur django-postman pour la messagerie et sur django-user-accounts pour les comptes utilisateurs. Mais j'étais clairement frustrés car connaissant les features offertes par les apps member et mp de zds, j'aurai préféré utiliser celles de zds. Mais voilà il fallait se rendre à l'évidence, forker une app de zds est impossible actuellement tant les modules sont liées entre eux.

ZdS apparait de l'extérieur comme une seule grosse bulle, on ne peut pas juste décider d'utiliser un module de zds et pourtant ça serait vachement utile. Je sais que c'est une volonté des développeurs de ZdS de développer ZdS POUR ZdS, et que ce n'est pas la priorité du tout, mais je repose tout de même la question :

Je pense que j'en aurai besoin dans le futur. L'idée est de pouvoir rajouter dans mon requirements.txt les apps zds-member et zds-mp et avec un paramétrage correct dans le settings.py et une surchage si besoin des templates, pouvoir avoir accès aux fonctionnalités (ainsi qu'à leur mise à jour).

Je ne peux qu'approuver ! Ça permettrait de développer d'autres sites web sans recoder la roue. Genre avoir les modules des membres, mps et tutoriels sans forum ni galerie.

Est-ce qu'un découpage sain des apps de ZdS est à prévoir un jour ou vaudrait mieux que je contribue à des trucs comme django-postman pour y rapatrier des features que je trouve cool de zds ?

Je dirais oui, si les moyens humains le permettent. C'est là le noeud du problème, on ne peut anticiper l'évolution du nombre de développeurs. Dans tous les cas, une plus grande modularité ne peut faire de mal.

En théorie, c'est une excellente idée. En pratique, on a un certain nombre de problèmes à résoudre avant de se lancer dans ce genre de manœuvres :

1. Aujourd'hui, l'association Zeste de Savoir est responsable du code du site, qui est mis à disposition mais sans grands efforts pour qu'il soit réutilisé (parce que le code est spécifique et que ce n'est pas la même manière de gérer le projet).
   Si en extrait des morceaux de ZdS en composants indépendants, qui devient responsable des éléments externalisés ? (la questions se pose pour chaque composant)
   • L'association n'a pas vocation à être éditrice de code autre que ses propres outils, lui confier cette responsabilité nécessiterait au moins un avis du CA, et probablement une modification des statuts.
   • Confier cette gestion à un tiers fait qu'on perds la main sur une partie du cycle de développement, ce qui peut être un problème ou non selon les morceaux externalisés.
2. Quels est la charge d'un tel redécoupage ? On est très limités en puissance de développement, c'est un critère auquel on échappera pas. Ici il faut tenir compte du découpage proprement dit, mais aussi des surplus éventuels en gestion, de la migration, etc.
3. En admettant que l'association reste éditrice des différents modules, comment gérer leur cycle de vie et leur intégration dans le site ?
4. En admettant qu'on laisse des tiers gérer les différents modules, comment gérer nos spécificités ? Que se passe-t-il si un module n'est plus maintenu, le réintègre-t-on ? (c'est un cas très fréquent y compris sur des projets très utilisés…)

Pour moi, les modules devraient rester en main de l'association. Par contre, il reste la problématique de la gestion des versions ainsi que des tickets !

Les modules changent-ils de version en même temps (ce qui donnerait la même version à chaque module) ? Les tickets sont-ils éparpillés sur le dépôt de chaque module ou seulement sur le principal ?

Si en extrait des morceaux de ZdS en composants indépendants, qui devient responsable des éléments externalisés ?

Logiquement l'association reste maître de ses composants, car il faut tout de même garder la main sur les fonctionnalités à intégrer. Donc on ne confie rien à un tiers et donc tout les problèmes liés à la gestion tierces n'ont pas lieux d'être.

Quels est la charge d'un tel redécoupage ?

• créer un dépot github au sein de l'organisation du site pour chaque composant à externaliser
• séparer la documentation, les tests
• séparer la logique du code et exposer les variables à travers le fichiers settings.py
• vérifier que tout ceci s'assemble comme il faut. Un découpage bien fait n'a aucune incidence sur les données

Comment gérer leur cycle de vie et leur intégration dans le site ?

Bonne question, a laquelle il faudrait prendre le temps d'y reflechir.

Actuellement on a déjà un module utilisé par ZdS qui est complètement externalisé, il s'agit de python-zmarkdown.

Notons qu'un découpage correct offre des avantages assez sympa aussi pour zds :

• Les composants sont moins gros, donc c'est moins compliqué de rentrer dans le code pour le nouvel arrivant
• On fait une release, on a un bug bloquant sur un composant ? pas grave on revient à la version précédente sur le composant fautif et le reste peut être mis à jour.
• Une personne tierce qui forke le composant a plus de chance et l'utilise dans son application a plus de chance de nous remonter des PRs de bugfix

Ça peut être une chouette idée en effet. D’ailleurs ça peut aussi faciliter la QA en diminuant la pile logicielle non ?

Ça permettrait aussi aux débutants comme moi, qui ont beau avoir lu le code, la doc, les forums et à peu près tout de se dire qu'ils peuvent modifier un truc sans risquer de faire exploser la machine par effet de bords.

J'aime bien l'idée, je voudrais juste signaler que le développement sera un poil plus pénible.

Si nous avons un projet Git pour chaque module et un projet "maitre" qui se contente d'appeler les autres modules pour construire ZdS, nous (les contributeurs de la plateforme) allons devoir jongler entre plusieurs modules pour pouvoir contribuer.

Par exemple, je veux rajouter une fonctionnalité dans le module tutorialv2 qui va créer un sujet (et donc toucher le module forum). Je vais devoir développer ma fonctionnalité dans le module des tutoriels, puis dans le module du forum et puis dans le projet "maitre" pour lier le tout et voir si tout fonctionne bien.

Je crois que vous comprenez à quel point ça peut devenir pénible !

Arrêtez-moi si je me trompe, mais l'intérêt de séparer les modules, c'est précisément de ne pas avoir besoin de toucher au module forum pour effectuer ce changement, non ?

Créer un sujet, c'est déjà possible. Mieux encore, on a une API en cours de développement qui permettra de le faire. Du coup, si une évolution dans le module tutorialv2 amène à devoir créer des sujets dans le forum, ne serait-il pas plus pertinent que le module tutorialv2 intègre un appel à l'API du module forum plutôt que de bidouiller directement celui-ci ?

De manière générale, je pense que « l'extraction » de modules hors du code principal gagnerait à être accompagnée de la mise en place d'une API pour ces modules, simplifiant la communication des autres modules avec eux. Accessoirement, ça réglerait le débat de savoir si les URL de l'API doivent dépendre du module ou non…

Dominus : Ce n'était qu'un exemple. Si tu en veux un autre, une contribution pourrait nécessiter le développement d'une nouvelle fonctionnalité dans le module X et dans le module Y. Dans tous les cas, même si la théorie le permet, dans la pratique il y a des cas où on ne pourra pas éviter de contribuer à plusieurs modules.

Concernant l'API, ça ne me semble pas une bonne idée pour plein de raisons. Par exemple, l'API n'est qu'au stade développement (même pas alpha) et le restera encore un bon bout de temps, elle est sujet à son propre cache de 15 minutes et elle est sujet au throttling. Il y a sans doute d'autres raisons auxquelles je ne pense pas à l'instant.

Il y a bien d'autres mécanismes qui permettent de développer des modules indépendants les uns des autres. Celui qui me vient naturellement à l'esprit (mécanisme sur lequel on se base pour le refactoring des notifications), c'est les signaux (et donc, la programmation événementielle). Puis, n'étant pas un expert Django, il y a sans doute d'autres mécanismes encore plus adaptés.

Gros +1, j'ai justement besoin d'un forum dans mon projet Django en cours.

Ce serait également sympa si d'éventuels rédacteurs / dev proposaient ce genre de module sous forme de tutoriel.

Gros plus un, mais comme a dit le renard, c'est pas si simple à mettre en place (via des splits qui sont en lecture seule ? Mais ça implique que chaque partie soit assez indépendante)

Pour moi, ça n'a pas à toucher à l'organisation Git. Chaque partie doit être assez indépendante pour vivre dans son propre projet avec son propre cycle de développement, et est utilisée en tant que dépendance « normale » du projet.

Sans ça, on perds la majorité de l'intérêt de la chose.

ça serait certainement pénible dans le sens ou tu ne toucheras plus à plusieurs modules sur une même PR (et quand on y pense, est-ce que c'est pas une bonne idée au final ?), mais ça s'arrête là.

Tu semble oublier quelque chose d'important dans ton inquiétude, il s'agit du concept d'api. En fait tu en parle plus loin, mais tu semble penser qu'il n'existe que des API REST. Avant l’avènement des Web Services, une API était tout simplement une interface qui permettait de communiquer avec une autre application. Ton module peut donc exposer une interface/api python destinée à être utilisée par d'autre application python. Et c'est même ainsi que fonctionne la grosse majorité des apps sur pypi

Pour reprendre ton exemple entre les tutoriels et les forums, le module forum devrait mettre à disposition une fonction qui permette de créer un topic depuis un autre module (ah tiens elle existe même déjà, mais elle est au mauvais endroit). Si tu jette un oeil à l'api python de django-postman par exemple, elle expose deux fonctions, une qui permet d'envoyer un mp à un utilisateur et une autre pour envoyer un mp à plusieurs utilisateurs, tout ceci avec les paramètres qui vont bien. Le reste fait partie de l'application elle même.

Je ne pense pas que les splits soient nécessaires pour ça. La gestion des dépendances avec pip, est pas mal pour ça. Il suffit que ton app zds-mp par exemple se trouve sur la forge python (la mise à disposition est automatique) pour que tu puisse le référencer dans le requirements.txt du projet maitre.

Ce qui peut faire réfléchir néanmoins, est la gestion des releases des apps connexes.

Tout à fait, j'en parlais même lors du précédent Zest'Meeting. "Réaliser un espace membre avec Django" par exemple me semble être un tutoriel qui trouvera son public.

Je me suis décidé à entreprendre le découpage pour sortir le module qui m’intéresse le plus : le module des membres. J'en ai donc fait une application à part et réutilisable pour n'importe quel projet Django qui démarre (j'en serais le premier utilisateur ).

Le code est passé au peigne fin et a gagné en stabilité. On se retrouve donc avec :

• Un module très stable : après quelques bugfix et une batterie de tests on passe d'environ 80% de couverture de tests à 94% sur le module.
• Un module qui se veut compatible (et travis est là pour nous l'assurer) :
  • Python 2.7, 3.3 et 3.4
  • Django 1.7 et 1.8
• Un module pleinement compatible windows (l'équivalent de Travis pour windows est là pour nous l'assurer) 32 et 64 bits

J'ai poussé aussi le module sur le pypi afin qu'il soit installable via pip install zds-member. Il doit rester deux trois bricoles à faire, mais je pense qu'on à la quelque chose de pas mal.

Actuellement tout se trouve là :

• Github
• documentation
• pypi

La mauvaise nouvelle c'est que ZdS ne peut pas encore en profiter car pour mes besoins j'ai du faire des choix qui ne sont pas compatibles avec ceux de ZdS (passage en anglais par défaut, suppression de Swagger pour la gestion de la doc de l'API, suppression des dépendances fortes avec les autres modules, … ) pour le moment.

La bonne nouvelle c'est que ZdS va pouvoir en profiter quand même parce que je prévois, une fois que j'aurai terminé mon projet de faire un tutoriel ici qui se base sur ce module.

je pense que le module de gallerie y passera aussi.

Il faudrait aussi un module Python (pas Django) pour les trucs utilisés dans tous les modules (comme la pagination par exemple) pour éviter de devoir faire des PRs sur chaque dépôt !

Du coup @firm1 faudrait que tu le mettes sur l'orga ZdS une fois que c'est Zds compatible non ?

Toutafè