Rationalisation des outils de developpement

Je reste personnellement persuadé qu'il y a beaucoup plus urgent et important que de chercher a virer node. Si les fronts en ont besoin, qu'on leur laisse !

Pour moi le seul prob actuellement avec node est qu'il fait (faisait?) régulièrement planter travis. Pour le reste je ne vois pas vraiment de raisons de leurs enlever.

Il faut être pragmatique et laisser les personnes qui travaillent choisir les outils qu'ils pensent le plus adapté aux besoins.

A noter que:

• avec la PR #1754, on a réglé quelques problèmes liés à certaines installations (quand une certaine version d'ImageMagick était installée)
• avec la PR #1734, on a réduit le nombre de plantage de travis
• avec la PR #1743, on a simplifié l'installation (les seuls dépendances à installer "à la main", et globalement, c'est node + npm, qui sont dispo soit par installer sur Win+Mac, soit sur les répos sur Linux), et on a plus besoin d'être en root pendant l'installation des outils de front (source d'erreurs chez certains).

En gros, tout le machin est relativement stabilisé, j'attends juste encore qu'un bugfix déjà prêt soit publié sur npm pour node-sass, et avec la PR #1752, je mettrais à jour les dépendances npm.

A mon sens, on arrive à quelque chose de suffisamment stable pour le demander à l'installation, et donc éviter d'avoir ce stack python que tu proposes. Je sais que tu tiens à simplifier au maximum, mais la, je pense qu'on a fait les démarches nécessaires pour que le stack avec node soit suffisamment fiable et facile d'installation

+1 pour kje

Bah après c'est pas dramatique non plus d'avoir les deux trucs qui peuvent tourner en même temps (en exclusif hein, pas en simultané ). Si firm1 prefere tout faire tourner avec python parce qu'il maîtrise mieux la techno et que tout s’intègre dans son IDE on va pas le blâmer de proposer ses solutions (tant que ca revient pas a virer les outils des autres je suis d'accord)

Qu'il garde cette stack sur son pc alors. Avoir deux stack en parallèle nous apportera forcément des bugs qui seront présent dans l'un et pas dans l'autres. Les outils ne seront jamais totalement identique. C'est une source de problèmes immense pour pas grand chose. C'est d'autant plus vrai qu'il va être compliqué d'avoir les deux sur une même machine et donc que les personnes qui toucheront aux dépendance de ces outils ne pourront pas tester sur les deux processus.

Encore plus que d'etre contre virer node.js sans raisons, je suis contre maintenir deux stacks officiellement. Il fait ce qu'il veut sur sa machine, mais sur le projet on ne peut pas supporter les deux simultanéments.

Encore plus que d'etre contre virer node.js sans raisons, je suis contre maintenir deux stacks officiellement. Il fait ce qu'il veut sur sa machine, mais sur le projet on ne peut pas supporter les deux simultanéments.

Je suis d'accord avec cette phrase.

Je reste personnellement persuadé qu'il y a beaucoup plus urgent et important que de chercher a virer node. Si les fronts en ont besoin, qu'on leur laisse !

C'est bien pour ça que j'essaye de conserver les deux. La doc serait ainsi allégée, car elle ne référencerait que la stack python, ce qui participe à réduire l'effet fouillis de la doc. Ici Node.js apporte du confort pendant le développement c'est certain, mais on dirait que c'est necessaire pour developper alors que non.

Pour comparer (en caricaturant) un peu, c'est comme si je disais qu'étant donné qu'Eclipse est un EDI qui apporte pas mal de fonctionnalité qu'on ne retrouve pas ailleurs, on a nécessairement besoin de ça (et donc de Java) pour developper sur ZdS. Ici c'est un peu pareil, quelque soit les outils qu'on utilise, la finalité c'est de modifier les fichiers Scss en css, de compiler des images et de minifier tout le tralala.

Pour moi le seul prob actuellement avec node est qu'il fait (faisait?) régulièrement planter travis. Pour le reste je ne vois pas vraiment de raisons de leurs enlever.

Malheureusement ce n'est pas le seul, on a aussi le risque que npm plante pendant une MEP (pas encore arrivé, mais possible) et ça, c'est plus problématique. Sans compter le fait qu'on est obligé d'utiliser des stratégies de déploiement qui ne sont pas natives django ce qui conduit à des réaction comme on peut voir ici

Stack officielle en full python avec proposition de la stack python+node.js pour ceux qui en ressentent le besoin ?

Stack officielle en full python avec proposition de la stack python+node.js pour ceux qui en ressentent le besoin ?

Dans ce sens là ça me va aussi. L'important est (les deux propositions à la fois) :

1. Que ça fonctionne avec le moins de soucis possibles
2. Qu'on ait une seule stack officielle – la plus simple

Si l'on passe par un stack python en prod, si j'ai bien compris (je suis pas du tout sûr de ce que je dis), c'est django qui s'occupera de délivrer les fichiers statiques, et les compileras à la volée, pour chaque requête. Peut-être qu'il y a un système de cache ou je ne sais quoi, mais aux dernière nouvelles, actuellement c'est nginx qui délivre les fichiers statiques précompilés. Donc niveau performances, je ne suis pas sûr que compiler les fichiers statiques à la volée, et le faire passer par python, puis par nginx, à chaque requête ne soit une solution…

Nan tu as mal compris je pense. Les fichiers statiques seront toujours compilé une seule fois (lors de la mise en prod de la release) et délivré par nginx ensuite pendant le fonctionnement normale, la seule différence c'est que cette compilation sera faite par Django au lieu de Node.

Si on passe en prod sur une stack python, les fichiers sont compilés uniquement à la MEP et servi par nginx (comme aujourd'hui).

C'est le rôle de la commande collectstatics dont on parle dans la discussion liée, d'ailleurs.

D'accord, j'ai effectivement mal compris.

Mais honnêtement, est-ce que la priorité est maintenant de virer node, avec tous les efforts faits récemment pour rendre tout ça accessible ? Peut-on attendre la prochaine MEP pour voir si node pose réellement problème, et est-ce que vous pouvez tester de votre côté les 2 étapes d'install nécessaire aux outils de front (à savoir, install de node + npm install dans le projet), et vérifier que tout est facile et fiable ?

Vraiment, je tiens personnellement à ce stack, parce que je le maîtrise, parce que c'est ce que les gens du front ont tendance à maîtriser (et pas django-pipeline), et parce que le stack actuel marche très bien, et est hyper optimisé, par rapport à ce que c'était avant l'arrivée de node (avant, on avait les mixins compass qui traînaient, un sprite 1.5x plus grand, des images pas minimisées, du javascript dont la syntaxe n'était pas vérifiée, sans compter le css minifié et les dépendances qui traînait sur le répo, ce qui alourdissait considérablement les diffs)

De plus, ce stack sera presque nécessaire lorsque l'on passera à Angular (ou autre), puisque l'on compte bien mettre en place des tests unitaires, voir E2E, d'ici un ou deux mois.

Dernier argument: on utilise bower, qui est basé sur node pour les dépendances front, type normalize.css, jquery, ou encore css3-media-queries. Il n'y a pas, à ma connaissance, d'outils semblables à bower en python, et l'on serait alors obligés (à moins de passer par un CDN externe, mais alors on multiplie par 3, sur des domaines différents, le nombre de requêtes nécessaire pour les dépendances front) d'inclure ces derniers sur le répo. C'est comme si, à une autre échelle, vous incluiez django direct sur le répo, pour pas avoir à passer par pip. Autant dire que c'est pas l'idéal.

Sérieusement, je suis d'accord avec les gens du front là. Le travail et les tests qui ont été réalisé ont vraiment réduit la difficulté à entrer dans le front. De gros efforts ont été portés sur la doc et on a même une deuxième personne pour aider sandhose. Là je pense que ce topic est clairement résolu. Que l'équipe front fasse un point régulier pour clarifier le tout avec tout le monde, c'est normal, qu'on tente encore d'envisager la suppression de node, c'est stérile, je trouve.

J'étais (très) réfractaire à tout les trucs Node (Sandhose témoignera) mais je dois dire que la simplification récente du truc m'a bien rassure. Certes je connais que les commandes de clean et build, mais c'est au moins suffisant pour la QA et meme pour faire un fix CSS si je le sens de temps en temps… Bref, perso Node ne me dérange plus vraiment.

Je suis entièrement d'accord avec Eskimon et artagis. Pour avoir fait ma première PR front hier je trouve que c'est extrêmement simple à mettre en place (pas forcément plus compliqué que virtualenv).

Sandhose et Sitphusen ont fait un travail remarquable sur la simplification et l'explication de ce qu'il fallait faire pour le front.

Bon visiblement les récents travaux de simplifications ont l'air d'avoir améliorer les choses. C'est positif.

Mais (parce qu'il y'a toujours un mais), ce qui me gène reste toujours l'immensité de la doc. L'intéret je le rappelle, c'est que tout doit être le plus léger possible pour un nouveau contributeur qui arrive. Mon objectif n'est pas de virer node pour le virer (j'ai d'autre chat à tuer), c'est surtout d’alléger le plus que possible notre stack (et par conséquent notre doc). Chez moi aussi j'ai bien Node.js d'installé depuis longtemps, mais c'est assez gros tout de même pour un contributeur occasionnel au projet.

La question que je me pose là comme ça c'est : Y'a t-il une vraie raison pour garder Node.js dans la Stack officielle, quand on sait que de l'on peut faire sans ?.

On n'y est pas encore à Angular, on a pas de tests unitaires coté front, les dépendances normalize et cie sont assez légère (c'est 2 trois fichiers dans le repo) et vu qu'on y touche jamais …

En gros, ce n'est pas parce que l'on a pris nos habitudes avec la stack qu'il faut penser qu'elle est facile à appréhendée pour le nouveau venu. Force est de constater que tout ceux qui ont tenter d'installer ZdS pour la première fois on toujours eu un blocage quelque part. Si on peut limiter les choses, je ne serais pas contre.

Force est de constater que tout ceux qui ont tenter d'installer ZdS pour la première fois on toujours eu un blocage quelque part

"Mais ca, c'était avant"

L'install maintenant c'est juste du apt-get et une commande pour npm si je dis pas de bétise

ça c'est encore produit recemment

Reste à fiabiliser pysolr alors

Troll : ça n'a absolument rien à voir avec Node.js.

Pas troll : relis mon propos