Le 10 décembre 2013 10:09, Nicolas <[email protected]> a écrit : > Bonjour Bruno, > > > > Je suis en train de me dire que passer à composer pour inclure twig (et > > pourquoi pas CB) ne serait pas une si mauvaise idée (je suis même > convaincu > > que c'est ce qu'il faudra faire à terme). > > > > Je suis déjà convaincu. J'attendais patiemment que l'idée fasse son chemin. > Tu peux déjà le faire pour CB : > https://packagist.org/packages/dotclear/clearbricks > > > Mes réticences/questionnements à coté : > > 1. par défaut tout s'installe dans vendor/ alors qu'aujourd'hui on est > > plutôt dans inc/libs > > > > Je ne vois pas le problème mais au pire on crée notre propre installeur : > http://getcomposer.org/doc/articles/custom-installers.md > > > 2. quand on installe les dépendances via composer, on tire aussi les > > répertoires de test (que ce soit CB ou Twig). > > > > Là encore je ne vois pas le problème. > > > 3. l'arborescence résultante est bien tordue. Pour twig, la lib est dans > > vendor/twig/twig/lib/Twig > > > > Je la refais ? Je ne ... >
Ce n'est pas réellement un problème, c'est juste la divergence par rapport à ce qu'on a actuellement, et les choix qu'on va/veut faire par rapport à ça. Pour ce qui est de l'arborescence, vu qu'on va supprimer un certain nombre de répertoires non utilisés lors du build (tests notamment), je trouve que ce sera assez moche de garder un twig perdu dans une arborescence vendor/twig/twig/lib/Twig, chacun des répertoires parents étant vide... Je trouve ça dommage que composer (ou packagist, au choix) ne permette pas de choisir des packages "épurés" orientés mise en prod. Je n'ai pas vraiment d'avis sur inc/libs vs vendor (même si vendor semble être la tendance actuelle), il y aura très peu d'impacts pour les autoloaders, et ça ne me dérange pas le moins du monde de déplacer les libs là-bas. Le sujet mérite discussion, en tout cas :) -- Bruno -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
