Je confirme je me souviens encore de mon mal de crane à essayer ça sous Windows en ligne de commande... ça m'a coupé l'envie.
Le 10/12/2013 17:24, Franck Paul 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 >> > > -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
