De façon assez étrange, ni Smarty, ni Redbean ne mentionnent composer dans leur documentation, et PHPMailer s'en passe parfaitement.
Parce que peut-être les développeurs de ces libs ne s'y sont pas vraiment intéressé ou ne veulent pas, ou sont réfractaires à certains changement ? D'ailleurs Redbean le dit bien : le gars est "conservateur".
Cela ne veut pas dire que Composer c'est de la merde.
Et tu noteras que tu cites quand même des projets vraiment vieux (voir à peine maintenu comme PHPMailer). Lourd passif donc.
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.
comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap
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.
J'ai plusieurs projets open source en PHP que je développe et maintien depuis des années. J'ai beau être compétent techniquement en HTML et CSS, je peux te dire une chose : ça me fais chier grave de faire les sites web de mes projets. Parce que je suis incompétent en design web et du coup, quand il faut que je refasse l'un deux, j'y passe des jours pour que ça ressemble à quelque chose. Ce temps, je préfère le passer à développer la lib. Donc je comprend très bien ceux qui choisissent bootstrap ou autre trucs "pour se faciliter la vie".
ni Smarty n'utilisent bootstrap sur leur site.
Ça c'est normal : le site de Smarty n'a pas bougé depuis 10 ans. Idem pour PHPMailer. Ils sont probablement comme moi : ils préfèrent passer du temps sur leur lib que sur le design de leur site.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc...
je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité.
parce que j'ai l'impression que tu n'as pas trop en tête les avantages qu'ils offrent...
Aujourd'hui, tout le monde boude PEAR,
Je te rassures, même avant tout le monde boudait Pear. Quelle a été la proportion de lib et de projets qui proposait un paquet Pear ? 0,5% ? 1%? Franchement on n'y trouvait pas grand chose.
Et maintenant avec Composer ? 70%, 80%, 90% ? Le nombre de projets dispo via Composer est sans commune mesure avec Pear.
Et si Composer a un tel succès, c'est bien parce qu'il offre quelque chose de mieux non ?
Perso je n'ai jamais aimé Pear.
Déjà, c'est un truc hyper fermé : il faut que ton projet respecte certaines règles, notamment le coding style (que je trouve horrible). Ensuite, il faut qu'il soit accepté par les gens qui gère Pear. Tu ne peux pas avoir de doublons en terme de fonctionnalité avec une autre lib. Au final, Pear ne propose pas grand chose. Ou alors des usines à gaz. Interroge toi par exemple pourquoi tu as choisi PHPMailer plutôt que leur lib de mail.
Ensuite, sur le serveur (en particulier avec Debian), ton depôt PEAR est forcément partagé par tous tes projets. Au final, tu te retrouve coincé : tu ne peux pas mettre à jour au risque de casser tes vieux projets, et donc tu ne peux pas profiter des dernières versions pour des nouveaux projets. Et même si tu veux mettre à jour, c'est la galère avec debian, on ne sait jamais ce qu'il faut faire vraiment (y a toujours eu des trucs qui cassaient chez moi). Ne serait-ce que pour mettre à jour PHPUnit avec Pear. ça a toujours été la galère (à cause principalement qu'il faille faire ça en sudo, qu'il faille modifier le include_path dans la conf PHP etc).
Alors qu'avec Composer, tu as un dépôt par projet, chaque projet évolue comme il veut, utilise les paquets qu'il veut. PHPUnit et les autres paquetes s'installent en deux coup de cuillère à pot. Pas besoin de droits spéciaux sur le système pour les installer. Peu importe au final le système : ton projet reste indépendant.
M'enfin comme tu l'as dit toi même Pear c'est plus un Framework qu'un gestionnaire de dépendance. Donc au final, peu de rapport avec Composer.
Les gros avantages de Composer, c'est qu'il fait un seul truc et le fait bien : installer des paquets et gérer les dépendances. Un apt pour PHP.
L'autre gros avantage de Composer : il génère un autoloader. Adieu tous les includes dans tout les sens pour charger une lib ! Et si en plus les lib utilisent les namespaces (en respectant PSR-0 ou PSR-4), l'autoloader est beaucoup plus efficace.
À 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).
Le pire, c'est que toutes ces libs modernes suivent les recommandations PSR, donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées.
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur. Je ne sais pas où tu as lu ça. Pour le moment, ils ont des recommandations pour le nommage des classes (PSR-0 et PSR-4), afin de faciliter le développement des autoloaders (que l'on n'a plus à développer si on utilise Composer), des recommandations sur le coding style (PSR-1 et PSR-2), et une recommandation sur l'interface d'un objet qui fait du log. Et ce qui est en discussion actuellement ce sont d'autres interfaces pour d'autres types d'objets courant (gestionnaire de cache, lib http...).
(donc non, ça ne servira pas qu'à Composer).
Bref, ce sont des choses pour améliorer l'interopérabilité entre les frameworks. Rien à voir avec la conf des serveurs.
Et puis ce ne sont que des recommandations. Pas obligé de les suivre.
composer qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n'ai jamais demandé et qui n'existe pas dans les archives
Composer installe ce que les paquets ont besoin, pas plus, pas moins. Si un paquet a une dépendance envers un autre paquet et qu'il n'utilise pas, la faute est au développeur, pas à Composer. Mauvais paquet, changer paquet. (ça tombe bien, contrairement à Pear, le choix est très vaste).
phpass - génération de hash sécurisés pour les mots de passe, en l'absence de blowfish
Avec la nouvelle api password de PHP, cette lib est devenu inutile et obsolète (voir dangereuse, vu qu'elle n'est plus maintenue ?).
leur usage abusif des namespaces
Les namespaces, c'est bon, mangez-en : ça évite les collisions de classes entre libs, ça facilite l'autoloading, ça permet une programmation moderne, ça force (un peu) à mieux organiser son code.
Je suis en train de "namespacer" mon framework, ça fait beaucoup de bien au final.
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.
# à 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é à 10.
Parce que peut-être les développeurs de ces libs ne s'y sont pas vraiment intéressé ou ne veulent pas, ou sont réfractaires à certains changement ? D'ailleurs Redbean le dit bien : le gars est "conservateur".
Cela ne veut pas dire que Composer c'est de la merde.
Et tu noteras que tu cites quand même des projets vraiment vieux (voir à peine maintenu comme PHPMailer). Lourd passif donc.
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.
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.
J'ai plusieurs projets open source en PHP que je développe et maintien depuis des années. J'ai beau être compétent techniquement en HTML et CSS, je peux te dire une chose : ça me fais chier grave de faire les sites web de mes projets. Parce que je suis incompétent en design web et du coup, quand il faut que je refasse l'un deux, j'y passe des jours pour que ça ressemble à quelque chose. Ce temps, je préfère le passer à développer la lib. Donc je comprend très bien ceux qui choisissent bootstrap ou autre trucs "pour se faciliter la vie".
Ça c'est normal : le site de Smarty n'a pas bougé depuis 10 ans. Idem pour PHPMailer. Ils sont probablement comme moi : ils préfèrent passer du temps sur leur lib que sur le design de leur site.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc...
parce que j'ai l'impression que tu n'as pas trop en tête les avantages qu'ils offrent...
Je te rassures, même avant tout le monde boudait Pear. Quelle a été la proportion de lib et de projets qui proposait un paquet Pear ? 0,5% ? 1%? Franchement on n'y trouvait pas grand chose.
Et maintenant avec Composer ? 70%, 80%, 90% ? Le nombre de projets dispo via Composer est sans commune mesure avec Pear.
Et si Composer a un tel succès, c'est bien parce qu'il offre quelque chose de mieux non ?
Perso je n'ai jamais aimé Pear.
Déjà, c'est un truc hyper fermé : il faut que ton projet respecte certaines règles, notamment le coding style (que je trouve horrible). Ensuite, il faut qu'il soit accepté par les gens qui gère Pear. Tu ne peux pas avoir de doublons en terme de fonctionnalité avec une autre lib. Au final, Pear ne propose pas grand chose. Ou alors des usines à gaz. Interroge toi par exemple pourquoi tu as choisi PHPMailer plutôt que leur lib de mail.
Ensuite, sur le serveur (en particulier avec Debian), ton depôt PEAR est forcément partagé par tous tes projets. Au final, tu te retrouve coincé : tu ne peux pas mettre à jour au risque de casser tes vieux projets, et donc tu ne peux pas profiter des dernières versions pour des nouveaux projets. Et même si tu veux mettre à jour, c'est la galère avec debian, on ne sait jamais ce qu'il faut faire vraiment (y a toujours eu des trucs qui cassaient chez moi). Ne serait-ce que pour mettre à jour PHPUnit avec Pear. ça a toujours été la galère (à cause principalement qu'il faille faire ça en sudo, qu'il faille modifier le include_path dans la conf PHP etc).
Alors qu'avec Composer, tu as un dépôt par projet, chaque projet évolue comme il veut, utilise les paquets qu'il veut. PHPUnit et les autres paquetes s'installent en deux coup de cuillère à pot. Pas besoin de droits spéciaux sur le système pour les installer. Peu importe au final le système : ton projet reste indépendant.
M'enfin comme tu l'as dit toi même Pear c'est plus un Framework qu'un gestionnaire de dépendance. Donc au final, peu de rapport avec Composer.
Les gros avantages de Composer, c'est qu'il fait un seul truc et le fait bien : installer des paquets et gérer les dépendances. Un apt pour PHP.
L'autre gros avantage de Composer : il génère un autoloader. Adieu tous les includes dans tout les sens pour charger une lib ! Et si en plus les lib utilisent les namespaces (en respectant PSR-0 ou PSR-4), l'autoloader est beaucoup plus efficace.
À 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).
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur. Je ne sais pas où tu as lu ça. Pour le moment, ils ont des recommandations pour le nommage des classes (PSR-0 et PSR-4), afin de faciliter le développement des autoloaders (que l'on n'a plus à développer si on utilise Composer), des recommandations sur le coding style (PSR-1 et PSR-2), et une recommandation sur l'interface d'un objet qui fait du log. Et ce qui est en discussion actuellement ce sont d'autres interfaces pour d'autres types d'objets courant (gestionnaire de cache, lib http...).
(donc non, ça ne servira pas qu'à Composer).
Bref, ce sont des choses pour améliorer l'interopérabilité entre les frameworks. Rien à voir avec la conf des serveurs.
Et puis ce ne sont que des recommandations. Pas obligé de les suivre.
Composer installe ce que les paquets ont besoin, pas plus, pas moins. Si un paquet a une dépendance envers un autre paquet et qu'il n'utilise pas, la faute est au développeur, pas à Composer. Mauvais paquet, changer paquet. (ça tombe bien, contrairement à Pear, le choix est très vaste).
Avec la nouvelle api password de PHP, cette lib est devenu inutile et obsolète (voir dangereuse, vu qu'elle n'est plus maintenue ?).
Les namespaces, c'est bon, mangez-en : ça évite les collisions de classes entre libs, ça facilite l'autoloading, ça permet une programmation moderne, ça force (un peu) à mieux organiser son code.
Je suis en train de "namespacer" mon framework, ça fait beaucoup de bien au final.
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.