J'ai donc rédigé une série de billet décrivant les possibilités offertes par ce format de fichier, et j'ai fait deux conférences sur ce thème lors du forum PHP 2010 et de la ConFoo 2011.
Enfin, j'ai prévu de diffuser Atoum, mon framework de tests unitaires pour PHP simple, moderne et intuitif, sous la forme d'une archive PHAR, afin qu'il soit le premier projet publique d'envergure à être diffusé sous cette forme.
Sauf que pour mon plus grand plaisir, je viens de me faire griller la politesse, puisque Loïc d'Anterroches vient d'annoncer cette semaine sur son blog la version 0.2 de son framework Photon, et que ce dernier se présente sous la forme d'une archive PHAR.
Et si je dis que c'est pour mon plus grand plaisir, c'est parce que Loïc, de son propre aveux, a fait ce choix à la suite de mon travail d'évangélisation, et c'est donc la preuve qu'il porte donc ses fruits.
Pour autant, ce mode de diffusion pour du code PHP est encore l'exception plutôt que la règle, puisque Fabien Potencier a fait le choix de ne pas l'utiliser pour Sismo, son outil d'intégration continue, alors qu'il est distribué sous la forme d'un fichier unique.
Cependant, je ne désespère pas de voir un jour PHAR utiliser massivement, dans le cadre de projets de petite ou grande envergure.
Je viens d'ailleurs d'avoir la confirmation que j'ai de bonnes raisons d'y croire, puisque, par pure coïncidence, Olivier Hoareau a présenté PM, qui utilise PHAR, hier soir lors d'un rendez-vous du Bordeaux PUG.
9 réactions
1 De Blount - 14/04/2011, 09:03
J'ai vu que le format phar peut utiliser la compression. Une question me vient à l'esprit : est-ce qu'à chaque accès (ex : nouvelle requête HTTP), le fichier est décompressé ?
Si tel est le cas, n'est-ce pas un gouffre pour les performances du serveur ? Imaginons l'utilisation d'un framework tel que Zend Framework.
2 De mageekguy - 14/04/2011, 09:12
@Blount : Oui et non. Sans la configuration ad hoc au niveau de PHP, il peut y avoir dégradation de performances. Mais avec l'activation de la directive phar.cache_list, il y a au contraire un gain.
Je t'invite à regarder les slides de ma conférence à la ConFoo, ou il y a un peu plus de détails.
3 De Steuf - 14/04/2011, 10:12
Phar c'est très bien il est d'ailleurs prévu dans un projet Open Source, mais pas sur l'intégralité, juste sur la partie "Plugin" du projet. C'est un très bon outils lorsque l'on a un projet à "diffuser". Pour des projets internes à une entreprise (donc privé) il n'a pas grand intérêt. Et justement le problème est bien là: Pour un projet qui est destiné à être diffusé, le but est quand même que cela soit compatible pour le plus grand nombre de plateforme, parce que bon lancer projet qui ne fonctionne que chez un hébergeur mutualisé par exemple c'est un peu se tirer une balle dans le pied. Enfin tout dépend la cible du projet, pour Atoum la question ne se pose pas... Pour un framework elle se pose beaucoup plus !
Et le réel problème est là (et de PHP 5.3 en général): Une très grande majorité d'hébergeur Français (je ne sais pas ce que ça donne dans le monde) n'ont toujours pas dépassé le cap de PHP 5.2 ! Seul OVH en France en mutualisé a PHP 5.3.
4 De Blount - 14/04/2011, 10:31
Je viens de parcourir tes slides. Je trouve que c'est assez prometteur comme solution.
Un truc qu'on ne pense pas forcément, c'est l'avantage d'utiliser ce format pour les frameworks. Parce que c'est quand même beaucoup plus lourd d'envoyer 3000 fichiers non compressés (ZF) sur un serveur par ftp (quand pas d'accès SSH) plutôt qu'un bon gros fichier compressé.
-
J'ai pu remarquer qu'il est possible de créer des programmes entier directement exécutable (même pour un site web). C'est intéressant comme fonctionnement.
Avec la protection de lecture seule (via code php), ça permet aussi de protéger des failles de sécurité qu'on peut retrouver (écriture de code dans des fichiers PHP).
-
Bref, je vais mettre ceci de coté, j'aurai quelque test à faire ^^
5 De Amaury - 14/04/2011, 17:45
Mon premier réflexe en lisant ce que tu dis sur Sismo, ça a été de me dire «Bah, si tout tient dans un seul fichier, pourquoi utiliser Phar ?». Et évidemment, juste derrière «Euh, mais en étant basé sur Silex, comment toute l'application peut bien tenir en un seul fichier ?». En ouvrant le fichier en question, on se rend compte qu'il s'agit d'une énorme concaténation de code PHP "minifié"... Alors là oui, un fichier Phar aurait sûrement été mieux.
D'un autre côté, je ne sais pas si les hébergeurs ont tendance à permettre l'exécution directe de fichiers Phar ; en cas de problème à ce niveau, le fait d'avoir un gros fichier PHP présente une compatibilité accrue.
De manière générale, les projets open source ont souvent une approche visant à faciliter la lecture et la modification du source tel qu'il est exécuté (oui, là pour Sismo c'est raté, il faut aller chercher les sources sur GitHub). Proposer d'un côté un Phar pour faciliter l'installation, et de l'autre un accès aux source, n'est pas encore entré dans toutes les mœurs.
Sans compter les projets qui se basent sur une arborescence éclatée, en cherchant la présence d'extensions dans certains répertoires. Il est évidemment possible de mettre en place des solutions pour obtenir le même résultat avec un "noyau" compartimenté dans un Phar, mais c'est moins évident au premier abord.
6 De Stéphane - 15/04/2011, 09:19
Au sein de notre projet, nous envisageons fortement d'utiliser PHAR pour la gestion des Plugin. Je tiens à souligner le travail de mageekguy sur l'évangélisation :). Nous rencontrons de plus en plus de personne nous demandant notre avis sur la question : PHAR a un très gros potentiel !.
Pour répondre à @Steuf
Baobapp plate-forme de cloud dédiée à PHP/MySQL propose PHP 5.3.5 et bientôt la version 5.3.6: plus d'info sur le phpinfo() : http://phpinfo.bapp.im/
7 De Steuf - 15/04/2011, 09:57
@Stéphane la question ne se pose pas pour moi ça fait longtemps que je suis passé sur du dédié
Mais en général les mutualisé en France... C'est loin d'être ce qui se fait de mieux.
8 De Loïc d'Anterroches - 15/04/2011, 23:29
Pour les performances, Phar met en cache une fois chargé les fichiers, donc dans mon cas, comme le .phar contient tout le code du serveur d'application, cela veut dire que je peux directement sortir un asset de mon .phar sans appel système. Cela donne d'excellentes performances.
9 De desfrenes - 24/04/2011, 18:01
Je viens de m'y mettre... ce qui m'a permis de voir que Github affichait parfaitement le contenu d'une archive phar (https://github.com/desfrenes/Azuki/...).
Ils sont forts chez Github