Oui, mais c'est encore plus simple et rapide d'extraire une archive.
en tant que développeur. Non. Pas du tout. Puisque j'ai même pas à connaitre l'url. Juste le nom du paquet. Une ligne dans le json (nom/version), composer install, et c'est terminé. Je veux mettre à jour ? je change la version dans le json, composer update. c'est terminé.
Alors qu'avec une archive : je dois aller la récupérer sur le site du projet, la dézipper dans mon projet, chercher à savoir comment inclure la lib, ou instancier son autoloader, et donc faire un include (voire plus) quelque part dans mon code. Ensuite, je veux mettre à jour (souvent plusieurs mois après) : faut que je retourne sur le site (dont j'ai oublié le lien, hop, détour par google), retélécharger à la mimine, dézipper les fichiers, ajouter les nouveaux fichiers dans le subversion/git, et supprimer les fichiers qui n'existent plus dans la nouvelle version (ce qui peut être fastidieux, et je parles en connaissance de cause), vérifier dans la doc que l'autoloading ou l'inclusion se fait toujours pareil...
Bah désolé, non, avec Composer, je n'ai pas toutes ces emmerdes, puisque Composer me télécharge tout ça automatiquement, qu'il m'évite à un inclure dans mon dépôt git ces libs externes, et parce que l'inclusion/autoloading, c'est Composer qui fait tout ça pour moi.
Je rajoute l'argument sécurité: si l'URL du dépôt de ton framework est comprise et que le dev qui utilise composer ne vérifie pas ce que composer télécharge...
Parce que le site où tu télécharge ton zip, il ne peut pas être compromis ? tu vérifie tout les zip des libs que tu télécharges ? cela voudrait dire que tu vérifie le contenu de chaque fichier ? et pourquoi alors tu ne pourrais pas le faire dans les sources posées dans le vendor/ par Composer ?
L'argument de sécurité est nul ici.
de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)
Perso je trouve ça bête pour un utilisateur final. Mais Magento n'est pas un bon exemple pour ton argumentaire. Le lien que tu montres, c'est la doc pour les développeurs (c'est marqué sur la page). Donc oui, là, utiliser Composer a un sens. Puisque si tu es développeur, cela veut dire que tu vas personnaliser Magento, lui rajouter du code pour des traitements metiers, des plugins ou que sais-je, et donc probablement installer d'autres lib (en utilisant Composer ou pas).
Pour les utilisateurs finaux, il faut aller voir sur le site pour les utilisateurs. Et qu'y trouve-t-on ? Oh, miracle, des tar.gz prêts à l'emploi ! ;-)
La majorité des paquets composer ne sont pas des applications complètes mais des librairies. A mon sens c'est une grosse différence.
Tu parlais de projets libre. Alors, à moins que pour toi une lib libre n'est pas un projet libre, je ne vois pas de différence.
Ce que je veux dire c'est que quand on développe une application à destination du "grand public", on cherche à lui donner une identité. Si on se contente d'un bootstrap à peine modifié, ....
Tu passes de PHP à Bootstrap, du coq à l'âne, donc des problématiques différentes. J'avoue que ton discours est très difficile à suivre.
Si les libs étaient proposées avec leur propre auto-loader (ce que fait, une fois encore, PHPUnit, PHPMailer, Smarty, etc.), il n'y aurait pas besoin de faire ça à la main.
Oui donc, au final, dans un projet, si tu utilises 25 libs, tu as alors 25 autoloaders, qui font quasiment la même chose. Bonjour les perfs. Avec Composer : on peut avoir un seul autoloader, en particulier si on utilise les namespaces (il est possible de lui indiquer des autoloaders spécifiques si nécessaire, par exemple ceux des libs ayant un autoloader spécifique).
C'est à la librairie de dire comme se charger, on n'a pas à le "deviner" ou le supposer.
Justement, avec Composer, on a encore moins à s'en charger, puisqu'il y a au final 0 include à faire après avoir installé une lib. Alors que, pour une lib "non composerifiée", il faut que tu saches quel fichier inclure (celui qui fait tout les includes de la lib ou qui déclare l'autoloader de la lib).
[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Je n'aime pas le code moderne. Évalué à 8.
en tant que développeur. Non. Pas du tout. Puisque j'ai même pas à connaitre l'url. Juste le nom du paquet. Une ligne dans le json (nom/version), composer install, et c'est terminé. Je veux mettre à jour ? je change la version dans le json, composer update. c'est terminé.
Alors qu'avec une archive : je dois aller la récupérer sur le site du projet, la dézipper dans mon projet, chercher à savoir comment inclure la lib, ou instancier son autoloader, et donc faire un include (voire plus) quelque part dans mon code. Ensuite, je veux mettre à jour (souvent plusieurs mois après) : faut que je retourne sur le site (dont j'ai oublié le lien, hop, détour par google), retélécharger à la mimine, dézipper les fichiers, ajouter les nouveaux fichiers dans le subversion/git, et supprimer les fichiers qui n'existent plus dans la nouvelle version (ce qui peut être fastidieux, et je parles en connaissance de cause), vérifier dans la doc que l'autoloading ou l'inclusion se fait toujours pareil...
Bah désolé, non, avec Composer, je n'ai pas toutes ces emmerdes, puisque Composer me télécharge tout ça automatiquement, qu'il m'évite à un inclure dans mon dépôt git ces libs externes, et parce que l'inclusion/autoloading, c'est Composer qui fait tout ça pour moi.
Parce que le site où tu télécharge ton zip, il ne peut pas être compromis ? tu vérifie tout les zip des libs que tu télécharges ? cela voudrait dire que tu vérifie le contenu de chaque fichier ? et pourquoi alors tu ne pourrais pas le faire dans les sources posées dans le vendor/ par Composer ?
L'argument de sécurité est nul ici.
Perso je trouve ça bête pour un utilisateur final. Mais Magento n'est pas un bon exemple pour ton argumentaire. Le lien que tu montres, c'est la doc pour les développeurs (c'est marqué sur la page). Donc oui, là, utiliser Composer a un sens. Puisque si tu es développeur, cela veut dire que tu vas personnaliser Magento, lui rajouter du code pour des traitements metiers, des plugins ou que sais-je, et donc probablement installer d'autres lib (en utilisant Composer ou pas).
Pour les utilisateurs finaux, il faut aller voir sur le site pour les utilisateurs. Et qu'y trouve-t-on ? Oh, miracle, des tar.gz prêts à l'emploi ! ;-)
Tu parlais de projets libre. Alors, à moins que pour toi une lib libre n'est pas un projet libre, je ne vois pas de différence.
Tu passes de PHP à Bootstrap, du coq à l'âne, donc des problématiques différentes. J'avoue que ton discours est très difficile à suivre.
Oui donc, au final, dans un projet, si tu utilises 25 libs, tu as alors 25 autoloaders, qui font quasiment la même chose. Bonjour les perfs. Avec Composer : on peut avoir un seul autoloader, en particulier si on utilise les namespaces (il est possible de lui indiquer des autoloaders spécifiques si nécessaire, par exemple ceux des libs ayant un autoloader spécifique).
Justement, avec Composer, on a encore moins à s'en charger, puisqu'il y a au final 0 include à faire après avoir installé une lib. Alors que, pour une lib "non composerifiée", il faut que tu saches quel fichier inclure (celui qui fait tout les includes de la lib ou qui déclare l'autoloader de la lib).