Migrer le build front (voir back) vers un Makefile

Coucou les devs !

Ma suggestion est simple dans le principe, et pourrait vachement simplifier l'installation & l'utilisation de notre stack. L'idée serait de passer déjà tout le process de build front vers un Makefile, voir même les tâches back (migrations, tests, lint, runserver…)

Pourquoi ? (côté front)

Parce qu'actuellement, on utilise gulp pour build le front. C'est sympa comme truc, mais on a un fichier de config de bien 200 lignes pour en gros du cp et du cat de fichiers, avec quelques transformations. Au début, on avait beaucoup de transformations différentes ; par exemple, pour le CSS, on avait SASS -> Autoprefixer -> Minifier. Maintenant, avec par exemple ma PR pour PostCSS, on a plus qu'un seul outil qui s'occupe de transformer, et donc toute la transformation qui peut se faire en une seule ligne de commande. Donc, pourquoi utiliser un outil comme gulp, si on peut faire la transformation en CLI, en une seule commande ?

Je suis en train aussi d'expérimenter avec browserify pour qu'on ait le même genre de système côté JS. Du coup, une commande pour build le CSS, une commande pour build le JS. Plus qu'a mettre ça dans un Makefile, et c'est bon. Plus besoin de Gulp.

Aussi, puisqu'on passe plus forcément par gulp, on peut tout à fait imaginer passer par des outils en python pour certaines choses ; par exemple, je passerais bien par glue pour la génération de sprites, sauf qu'on peut pas vraiment le faire proprement avec gulp. Avec un Makefile, on peut tout à fait mixer ce genre d'outils sans problèmes. Ca permettrait de virer des dépendances comme sprity, qui ont tendance à avoir des bindings natifs en C côté node, qui plantent une fois sur deux à l'install. En gros, une install vachement plus stable côté front. (glue utilise Pillow, qu'on a déjà dans notre stack ; donc pas de binding natif en plus côté python)

Enfin, au lieu d'utiliser le watch de gulp pour recompiler à la volée, on peut utiliser le watch des outils directement (donc de PostCSS et de Browserify), qui sont vachement plus performants, et sûrement moins gourmands.

Pourquoi ? (côté back)

La, j'ai pas fait plus de recherche que ça, y'a sûrement des soucis genre "comment qu'on fait pour lancer que quelques tests ? ou donner des arguments spéciaux à manage.py ?". C'est un peu pour ça que je crée ce topic: pour récolter les avis et les idées pour palier à ce genre de problèmes.

Entre flake8, les commandes dans manage.py, les commandes d'install pip, tox et les commandes pour le coverage, ça fait beaucoup d'outils différents avec des commandes différentes, qui sont à chaque fois plus ou moins documentées.

Ca serait bien que tout ça soit résumé dans un Makefile.

Un truc genre: (faites pas attention aux noms ni à l'exactitude des commandes, c'est juste pour l'idée)

• make lint-python -> flake8 --exclude=migrations,urls.py,settings.py --max-line-length=120 zds
• make run -> python manage.py runserver 0.0.0.0:8000
• make install-pip -> pip install --upgrade -r requirements.txt -r requirements-dev.txt

…

Pour un dev lambda, ca donne quoi ?

En supposant qu'on ait déjà make + les outils du stack actuel (python, node, + les deux trois libs natives type libjpeg) d'installé, l'idéal serait qu'on ait genre, pour les devs, juste à lancer make setup pour installer les dépendances npm + pip + migrer la DB si besoin, puis make run pour lancer le serveur python + le build front en mode watch (donc qui compile à la volée).

Pareil pour le lint et les tests ; suffirait de faire genre un make lint et make test pour respectivement linter le front + le back, et pour lancer les tests front (un jour ) et les tests back.

Pareil pour la doc ; make doc pour générer la doc back + front (parce qu'il parait qu'un certain Sandhose fait gaffe en ce moment à chaque fois à mettre plein de docstring dans son JS, pour qu'on ait un de ces quatre une doc auto pour le front c: )

Et pourquoi pas faire des tâches pour tester les PR ? Genre make pr-XXXX pour pull + checkout une PR, avec le build front et les migrations qui vont avec ? Ou encore lancer une release, qui update tous les champs de version (dans le package.json + setup.py) et crée le tag/la branche comme il faut ? Même si la, je vais peut-être un peu loin, ça serait GÉNIAL, nan ? \o/

Donc voila, qu'est-ce que vous en pensez, plutôt ça uniquement pour le front (ce que je ferais sûrement de toutes façons pour le front ; gulp devient un peu relou en ce moment), ou on fait aussi quelque chose pour le back ? Comment rendre ça le plus simple possible, voir compatible Windows ?

Un peu de lecture qui m'ont inspiré sur la partie "utiliser make comme outil de build pour du front":

• http://www.sitepoint.com/using-gnu-make-front-end-development-build-tool/
• https://algorithms.rdio.com/post/make/
• http://west.io/post/2015/04/11-frontend-builds-with-makefiles/

Makefile partout (justice nulle part).

Makefile partout Autant unifier le plus possible…

+1000

Pourquoi pas. Par contre, on n'a plus de compatibilité avec Windows, si ?

On m'as déjà perdue depuis un certain temps. Puis y'a toujours mingw, pour make sous windows

Je ne suis pas spécialement contre mais cela me semble bizarre pour le côté back-end. Les commandes que tu cites sont paramétrables à plein de niveaux. Est-ce que ton script en Makefile gardera ce paramétrage ou faudra-t-il reprendre et maintenir tous les paramétrages possibles pour une commande donnée ?

Malheureusement on ne pas passer d'arguments supplémentaires à make, c'est sa limitation la plus célèbre.

Note que c'est un peu comme tout task runner : tu peux y définir autant de tâches que tu veux, y'aura toujours tel truc spécifique qu'il faudra faire à la main ou qu'il faudra ajouter comme tâche.

si make est comme "tout task runner" pourquoi ne pas se contenter de npm/gulp?

Je trouve que sandhose a bien résumé pourquoi.

On n'a pas besoin de gulp est ses 6Mo de dépendances pour faire ça :

1
2
3
4
5
6

gulp.task("jshint", function() {
  return gulp.src([path.join(sourceDir, scriptsDir, "*.js"), "!" + path.join(sourceDir, scriptsDir, "_custom.modernizr.js")])
    .pipe($.jshint())
    .pipe($.jshint.reporter("jshint-stylish"));
});
gulp.task("test", ["jshint"]);

Quand on peut faire ça :

1
2

test:
    jshint

(Oui oui, ça fait la même chose. Suffit de flanquer le bon .jshintrc. Au passage, autant passer par eslint. Comme ça pas besoin de jshint-stylish-truc.)

Je fais confiance aux devs front pour leurs outils mais je ne pense pas que c'est pertinent pour le côté back-end.

Bah, c'est pas très important ça Andr0.

Ce qui est sûr c'est qu'un makefile contairement à gulp est adapté au back. Du coup, personne va obliger les devs back d'utiliser ce makefile, et ça va pas empêcher qui que ce soit d'ajouter des tasks back au makefile.

Une fois ceci fait, tu pourras évidemment toujours choisir entre taper make lintpy et rappeler flake8 --exclude=migrations,urls.py,settings.py --max-line-length=120 zds de ton historique.

Oui et non.

Oui, je vais sans doute pas l'utiliser.

Non parce que, si nous officialisons ce Makefile pour le back-end, je m'engage quand même à le maintenir si je fais évoluer les commandes.