M'enfin bon, même si des libs comme celle-là ne sont pas fournie en paquet Composer, c'est juste 3 lignes de code supplémentaires à rajouter dans ton composer.json pour les intégrer dans ton projet. Pas la mort quoi.
Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.
Je suis désolé mais non, pour un débutant qui veut utiliser son application, ce n'est pas plus simple de faire:
que d'extraire une archive. D'autant que composer semble ne pas fonctionner partout de la même façon: sous Mac OSX, l'installation de CakePHP se fait exactement comme dans la doc officielle. Sous Debian, l'arborescence de vendor n'est pas la même et il devient impossible de charger le bootstrap de CakePHP sans modifier une variable pour mette le chemin en dur parce que sous Debian, il chope le repo git au lieu du repo PEAR (ou l'inverse, je ne sais plus).
composer est bien pour gérer les dépendances d'un projet pro, statique, où personne ne va mettre son nez dedans, mais pour un projet Libre, je pense que ce n'est pas une bonne solution.
J'ai l'impression que tu ne maintiens pas de projet public pour dire ça, ou alors tu es super compétent en design web et c'est super facile pour toi de pondre un design html/css.
Je suis loin d'être compétent en web design. Mais bootstrap, comme tout framework qu'il soit front ou back end, est fait pour industrialiser. Quand on code une appli libre, on n'industrialise pas. On industrialise quand on se fait plein de petits projets pour soi-même. Moi aussi j'utilise bootstrap quotidiennement pour mes projets perso (genre gestion DNS, gestion d'Apache, PKI, etc.), mais pour des applications Libres, je n'utilise que normalizer (sur lequel repose bootstrap). Pour les projets pros, pareil.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc...
Je me suis peut être mal exprimé: je ne dis pas que bootstrap c'est de la merde, je dis qu'il faut arrêter d'en mettre partout. Je reste d'accord avec ce que tu dis.
Je te rassures, même avant tout le monde boudait Pear
Pas faux, le problème d'être élitiste :)
ton depôt PEAR est forcément partagé par tous tes projets
C'est un détail, mais non. Tu peux parfaitement utiliser PEAR pour un unique projet (c'est ce que fait Roundcube par exemple, qui n'a jamais nécessité d'installer PEAR alors qu'il en utilise des libs)
Pareil Horde permet d'être installé avec sa propre instance de PEAR (leur site est + ou - down là sinon j'aurai mis un lien).
À l'usage on se rend compte que ça apporte plus de souplesse, moins de tracas, et plus de perf (pas de chargement de classes non utilisées)
Oui, je suis d'accord, mais ça serait mieux sans les pseudo-dépendances qui n'existent pas dans les archives !
Ou alors, les paquets composer sont structurés différemment des archives, ce qui forcerait les dev à maintenir deux paquets différents ?
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur.
Oui pardon je me suis enflammé ^
Ceci dit ils parlent d'interopérabilité, j'ai pensé que ça avait un sens un poil plus large...
Pour finir, Composer, on peut s'en passer, mais c'est devenu la norme maintenant pour distribuer et installer des libs en PHP. L'ignorer ou le dénigrer n'aidera pas dans tes projets présent et futurs.
C'est bien là que le bât blesse: quelque chose qui n'a rien à voir avec PHP devient la norme pour développer avec PHP.
Si le gestionnaire de dépendance était partie intégrante de PHP, les choses seraient différentes, mais là c'est un projet lambda. Et forcer à son utilisation est contraire à la philosophie du Libre.
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . En réponse au journal Je n'aime pas le code moderne. Évalué à 2.
Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.
Je suis désolé mais non, pour un débutant qui veut utiliser son application, ce n'est pas plus simple de faire:
que d'extraire une archive. D'autant que composer semble ne pas fonctionner partout de la même façon: sous Mac OSX, l'installation de CakePHP se fait exactement comme dans la doc officielle. Sous Debian, l'arborescence de vendor n'est pas la même et il devient impossible de charger le bootstrap de CakePHP sans modifier une variable pour mette le chemin en dur parce que sous Debian, il chope le repo git au lieu du repo PEAR (ou l'inverse, je ne sais plus).
composer est bien pour gérer les dépendances d'un projet pro, statique, où personne ne va mettre son nez dedans, mais pour un projet Libre, je pense que ce n'est pas une bonne solution.
Je suis loin d'être compétent en web design. Mais bootstrap, comme tout framework qu'il soit front ou back end, est fait pour industrialiser. Quand on code une appli libre, on n'industrialise pas. On industrialise quand on se fait plein de petits projets pour soi-même. Moi aussi j'utilise bootstrap quotidiennement pour mes projets perso (genre gestion DNS, gestion d'Apache, PKI, etc.), mais pour des applications Libres, je n'utilise que normalizer (sur lequel repose bootstrap). Pour les projets pros, pareil.
Je me suis peut être mal exprimé: je ne dis pas que bootstrap c'est de la merde, je dis qu'il faut arrêter d'en mettre partout. Je reste d'accord avec ce que tu dis.
Pas faux, le problème d'être élitiste :)
C'est un détail, mais non. Tu peux parfaitement utiliser PEAR pour un unique projet (c'est ce que fait Roundcube par exemple, qui n'a jamais nécessité d'installer PEAR alors qu'il en utilise des libs)
Pareil Horde permet d'être installé avec sa propre instance de PEAR (leur site est + ou - down là sinon j'aurai mis un lien).
Oui, je suis d'accord, mais ça serait mieux sans les pseudo-dépendances qui n'existent pas dans les archives !
Ou alors, les paquets composer sont structurés différemment des archives, ce qui forcerait les dev à maintenir deux paquets différents ?
Oui pardon je me suis enflammé ^
Ceci dit ils parlent d'interopérabilité, j'ai pensé que ça avait un sens un poil plus large...
C'est bien là que le bât blesse: quelque chose qui n'a rien à voir avec PHP devient la norme pour développer avec PHP.
Si le gestionnaire de dépendance était partie intégrante de PHP, les choses seraient différentes, mais là c'est un projet lambda. Et forcer à son utilisation est contraire à la philosophie du Libre.