Ç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" <[email protected]> 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 <[email protected]> a écrit : > > > Le 10 décembre 2013 15:04, Denis Jean-Christian <[email protected]> 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 - [email protected] - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > Franck > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
