mitsuhiko (Armin Ronacher, le créateur de flask), écrit le 7 mai 2014 :
Mon plan est que d'ici le mois prochain il y ait une nouvelle release de Flask avec Click embarqué ainsi que la recommandation de l'utiliser
[...]
Vu combien d'extensions utilisent Flask-Script actuellement et à quel point il est devenu populaire, j'aimerai qu'on puisse trouver une solution pour tout migrer sur Click sans pour autant causer à tous beaucoup de frustration.
[...]
Pour répondre à la question évidente pourquoi pas Flask-Script:
Flask-Script est vieux et victime de deux changements majeurs dans Flask. Le principal problème est que Flask-Script lance un contexte de requête même si il n'y a pas de raisons de faire cela.
Flask-Script charse l'application très tôt ce qui cause des soucis pour le rechargeur (reloader) pendant le développement.En particulier cela veut dire qu'une erreur de syntaxe va faire crasher le rechargeur. Ce veut aussi dire qu'avec le rechargeur activé, le code de plus haut niveau est exécuté deux fois. L'intégration de click dans Flask résout cela.
[...]
Réponse de miguelgrinberg (grosse pointure dans la communauté, a notamment écrit le flask mega tutorial) le 9 mai 2014
@mitsuhiko J'ai jeté un coup d’œil à ta couche d'intégration de Click. Il semblerait que le code qui s'occupe de résoudre les deux limitations de Flask-Script que tu as mentionner ne sont pas spécifiques à Click du tout.
En fait, en quelques minutes de hacking, j'ai été capable de résoudre les soucis avec Flask-Script de la même manière.
[...]
S'ensuit quelques discutions sur le comment et malheureusement pas assez le pourquoi.
Et la dernière réponse du fils à l'heure actuelle (miguelgrinberg du 4 avril 2015) pleine de bon sens :
Ce que les gens semble oublier, c'est que nous sommes en train de parler de systèmes gestion de ligne de commande. Il s'agit de systèmes simples dont les patterns sont connus et résolus depuis longtemps. Oui, Click a une façon originale de définir les arguments d'une ligne de commande ce qui le rend pratique et même fun à utiliser, mais au bout du compte, de mon point de vue la ligne de commande dans une application Flask est une partie extrêmement petite de mes problèmes, honnêtement ce ne fait pas de différences pour moi de devoir utiliser Click ou Flask-Script car les deux rendent la tache simple. Et Flask-Script a l'avantage d'être compatible avec argparse, ce que Click n'est pas.
[...]
Au final je vois ça comme un bel exemple de NIH, Armin est connu pour avoir créé tout un écosystème d'excellente qualité (maintenant le projet pallets) ce qui fait que les dépendances des ses projets sont presque tout le temps d'autres projets à lui (par exemple toutes les dépendances de Flask, ainsi que toutes les dépendances de ces dépendances).
Il a donc créé Click qui est un super outil, simplement dans l'écosystème Flask il existe déjà Flask-Script qui marche bien et est le standard de-facto.
S'ensuit des arguments foireux en faveur de Click sans pour autant prendre en compte ceux de Flask-Script, au hasard que ça va foutre un énorme bordel dans les extensions qui sont justement la force de Flask. On nous explique c'est in-dis-pen-sable d'avoir un module de command line livré dans Flask (c'est vrai que faire $ flask ma-commande c'est tellement mieux que $ ./manage.py ma-commande, ça justifie largement un changement majeur).
Puis une situation de pourrissement : rien ne se passe en 2 ans, le fil est abandonné depuis 1 an.
La question majeure de la migration des extensions reste en suspend et on passe l'évolution à mi-mot : le module command line est dans la release, mais ce n'est qu'un détail qu'il utilise Click.
À terme on aura donc au sein d'une même application des extensions en Flask-Script et d'autres en Click, le tout parce que l'ancienne implémentation du module d'autoreload de Flask était pas top, oui ça n'a aucun rapport...
# Mais pourquoi click ?
Posté par G.bleu (site web personnel) . En réponse à la dépêche Sortie de Flask 0.11. Évalué à 10. Dernière modification le 16 juin 2016 à 11:16.
Le plus gros soucis de cette version pour moi est l'arrivée de click en dépendance.
L'issue (https://github.com/smurfix/flask-script/issues/97) résume bien le bordel :
mitsuhiko (Armin Ronacher, le créateur de flask), écrit le 7 mai 2014 :
Réponse de miguelgrinberg (grosse pointure dans la communauté, a notamment écrit le flask mega tutorial) le 9 mai 2014
S'ensuit quelques discutions sur le comment et malheureusement pas assez le pourquoi.
Et la dernière réponse du fils à l'heure actuelle (miguelgrinberg du 4 avril 2015) pleine de bon sens :
Au final je vois ça comme un bel exemple de NIH, Armin est connu pour avoir créé tout un écosystème d'excellente qualité (maintenant le projet pallets) ce qui fait que les dépendances des ses projets sont presque tout le temps d'autres projets à lui (par exemple toutes les dépendances de Flask, ainsi que toutes les dépendances de ces dépendances).
Il a donc créé Click qui est un super outil, simplement dans l'écosystème Flask il existe déjà Flask-Script qui marche bien et est le standard de-facto.
S'ensuit des arguments foireux en faveur de Click sans pour autant prendre en compte ceux de Flask-Script, au hasard que ça va foutre un énorme bordel dans les extensions qui sont justement la force de Flask. On nous explique c'est in-dis-pen-sable d'avoir un module de command line livré dans Flask (c'est vrai que faire
$ flask ma-commandec'est tellement mieux que$ ./manage.py ma-commande, ça justifie largement un changement majeur).Puis une situation de pourrissement : rien ne se passe en 2 ans, le fil est abandonné depuis 1 an.
La question majeure de la migration des extensions reste en suspend et on passe l'évolution à mi-mot : le module command line est dans la release, mais ce n'est qu'un détail qu'il utilise Click.
À terme on aura donc au sein d'une même application des extensions en Flask-Script et d'autres en Click, le tout parce que l'ancienne implémentation du module d'autoreload de Flask était pas top, oui ça n'a aucun rapport...