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).

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

2. quand on installe les dépendances via composer, on tire aussi les répertoires de test (que ce soit CB ou Twig).

3. l'arborescence résultante est bien tordue. Pour twig, la lib est dans vendor/twig/twig/lib/Twig

Ce qui laisse plusieurs possibilités : * opter pour vendor en lieu et place de inc/libs pour clearbricks, Twig, voire d'autres style ckeditor, et ne plus se prendre la tête avec des post-install * faire un script qui va déplacer/copier uniquement ce dont on a besoin dans inc/libs/[lib] en enlevant la sous-arborescence inutile et les tests (genre vendor/twig/twig/lib/Twig vers inc/libs/Twig) Pour la première possibilité, il faudra triturer le build pour virer tous les fichiers inutilisés.

Z'en pensez quoi ?

Le 10 décembre 2013 15:04, Denis Jean-Christian <contact(a)jcdenis.fr&gt; a écrit : > J’espérais ne jamais voir passer cette question étant réfractaire à tout > changement ;-) Modifier la structure de DC juste parce qu'un jour un > gars a dis "Je mets dans vendor/ et non plus dans libs/" et que tout le > monde à dit: "C'est un génie !" Perso je ne vois que très peu d’intérêt > du bout de ma lorgnette, je vois ça comme alourdir la lisibilité de DC. > > Bon sinon maintenant que j'ai ronchonné, si ça permet de se rapprocher > de ce qui se fait maintenant et peut-être par la suite faciliter > l'inclusion de librairies, autant le faire à fond et passer à vendor/ en > gardant toute l'arbo "standard" même si lourde. Comme dit dans une des > réponses ça ne casse rien de bouger de l'un vers l'autre. Et oui il faut > faire une version "prod" sans tous les test et tout et tout mais je ne > sais pas comment on fait. > > C'est surtout pour simplifier le truc que je voyais l'histoire du /vendor. Aujourd'hui c'est comme ça que fonctionne composer, et c'est la tendance du web. Quelle que soit la solution et l'emplacement retenus, on y gagnera au niveau du mercurial : * Suppression d'une dépendance "sub-project" dans le repo dc * Suppression du source Twig du hg (qui est en doublon du repo git officiel de twig) Après, 2 solutions : # Soit on prend composer out of the box et on s'adapte : /inc/libs devient /vendor, et on met à jour le script de build pour proprifier le code de dc # Soit on tord un peu le cou à composer.json avec un installer dédié, ou des traitements type hook "post-install-cmd" dans composer, qui sera plus sujet à changements si composer évolue. > Petite question: Pour avoir voulu un jour utiliser composer chez moi > avec une belle perte de temps et sans résultat (oui, je suis nul pour > ces choses) j'espère qu'on n'aura pas besoin de faire le même bordel > pour installer Dotclear et ses libs (prod ou dépot) demain... ? > Heu ... là il suffit de faire php composer.phar install après avoir fait un pull du dépôt, et tout est déployé comme il faut :) -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Ça doit pas être bien compliqué de faire un hook hg qui va télécharger/lancer composer (c'est un simple fichier) après chaque pull Le 10 déc. 2013 17:25, "Franck Paul" <carnet.franck.paul(a)gmail.com&gt; a écrit : > Et donc, quelqu'un qui voudrait contribuer va devoir installer un > "composer" (que même pas je sais comment ça s'installe) et tâter de la > ligne de commande. > > Ça se klingonise, déjà qu'on avait pas des masses de contributions, on va > assécher la source là, non ? > > > Le 10 décembre 2013 16:09, Bruno <dsls(a)morefnu.org&gt; a écrit : > > > Le 10 décembre 2013 15:04, Denis Jean-Christian <contact(a)jcdenis.fr&gt; a > > écrit : > > > > > J’espérais ne jamais voir passer cette question étant réfractaire à > tout > > > changement ;-) Modifier la structure de DC juste parce qu'un jour un > > > gars a dis "Je mets dans vendor/ et non plus dans libs/" et que tout le > > > monde à dit: "C'est un génie !" Perso je ne vois que très peu d’intérêt > > > du bout de ma lorgnette, je vois ça comme alourdir la lisibilité de DC. > > > > > > Bon sinon maintenant que j'ai ronchonné, si ça permet de se rapprocher > > > de ce qui se fait maintenant et peut-être par la suite faciliter > > > l'inclusion de librairies, autant le faire à fond et passer à vendor/ > en > > > gardant toute l'arbo "standard" même si lourde. Comme dit dans une des > > > réponses ça ne casse rien de bouger de l'un vers l'autre. Et oui il > faut > > > faire une version "prod" sans tous les test et tout et tout mais je ne > > > sais pas comment on fait. > > > > > > > > C'est surtout pour simplifier le truc que je voyais l'histoire du > /vendor. > > Aujourd'hui c'est comme ça que fonctionne composer, et c'est la tendance > du > > web. > > > > Quelle que soit la solution et l'emplacement retenus, on y gagnera au > > niveau du mercurial : > > * Suppression d'une dépendance "sub-project" dans le repo dc > > * Suppression du source Twig du hg (qui est en doublon du repo git > officiel > > de twig) > > > > Après, 2 solutions : > > > > # Soit on prend composer out of the box et on s'adapte : /inc/libs > devient > > /vendor, et on met à jour le script de build pour proprifier le code de > dc > > # Soit on tord un peu le cou à composer.json avec un installer dédié, ou > > des traitements type hook "post-install-cmd" dans composer, qui sera plus > > sujet à changements si composer évolue. > > > > > > > Petite question: Pour avoir voulu un jour utiliser composer chez moi > > > avec une belle perte de temps et sans résultat (oui, je suis nul pour > > > ces choses) j'espère qu'on n'aura pas besoin de faire le même bordel > > > pour installer Dotclear et ses libs (prod ou dépot) demain... ? > > > > > > > Heu ... là il suffit de faire php composer.phar install après avoir fait > un > > pull du dépôt, et tout est déployé comme il faut :) > > -- > > Dev mailing list - Dev(a)list.dotclear.org - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > Franck > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 10 décembre 2013 19:08, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > et ce simple fichier il s'installe tout seul ? oui > il est fourni avec Dotclear? Non > il est dans le dépôt ? > Non Un tel fichier n'a pas sa place dans le dépôt (pas plus que Twig d'ailleurs), il se télécharge là : http://getcomposer.org/download/ Une fois pour toutes dans un clone hg local, ou en global pour la machine Et il se lance aussi une fois pour toutes (sauf changement de dépendances), ça ne casse vraiment pas trois pattes à un canard :) On est sur du DRY : on ne va pas gérer les versions de composants qui sont déjà gérés dans des outils de VCS par ailleurs... -- Bruno -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 11 décembre 2013 09:05, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > Ok c'est installé (va juste falloir que je me souvienne où il est à chaque > fois que le lancerai la commande idoine) > Je n'ai rien contre mettre un script quelque part dans le dépôt qui va aller chercher composer le cas échéant et éventuellement le lancer, en revanche je ne suis pas chaud du tout pour mettre composer.phar dans hg

composer n'aurait pas sa place dans build-tools finalement ?

Euh, je viens de le mettre dans un endroit accessible via mon PATH mais nada, un : php composer.phar me renvoie un laconique : Could not open input file: composer.phar

Le 11 décembre 2013 11:30, Nicolas <nikrou77(a)gmail.com&gt; a écrit : > Le 11 décembre 2013 10:49, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > écrit : > > > composer n'aurait pas sa place dans build-tools finalement ? > > > > Peu importe mais pas d'intérêt à le versionner. Personnellement sur tous > mes projets je ne le versionne jamais. Il est installé et accessible dans > mon PATH. > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Ah ok, finalement ça devait être simple, mais c'est un peu plus compliqué, j'ai comprite. Le 11 décembre 2013 13:05, Nicolas <nikrou77(a)gmail.com&gt; a écrit : > Le 11 décembre 2013 12:48, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > écrit : > > > Euh, je viens de le mettre dans un endroit accessible via mon PATH mais > > nada, un : > > > > php composer.phar > > > > me renvoie un laconique : > > > > Could not open input file: composer.phar > > > > > Non ! Car là php le cherche en local. Tu le rends exécutable et tu fais > composer.phar direct > > > > > > > Le 11 décembre 2013 11:30, Nicolas <nikrou77(a)gmail.com&gt; a écrit : > > > > > Le 11 décembre 2013 10:49, Franck Paul <carnet.franck.paul(a)gmail.com > > a > > > écrit : > > > > > > > composer n'aurait pas sa place dans build-tools finalement ? > > > > > > > > > > Peu importe mais pas d'intérêt à le versionner. Personnellement sur > tous > > > mes projets je ne le versionne jamais. Il est installé et accessible > dans > > > mon PATH. > > > -- > > > Dev mailing list - Dev(a)list.dotclear.org - > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > -- > > Franck > > -- > > Dev mailing list - Dev(a)list.dotclear.org - > > http://ml.dotclear.org/listinfo/dev > > > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Et donc, quelqu'un qui voudrait contribuer va devoir installer un "composer" (que même pas je sais comment ça s'installe) et tâter de la ligne de commande. Ça se klingonise, déjà qu'on avait pas des masses de contributions, on va assécher la source là, non ?