Phar away

le lundi 5 janvier 2015

For a long time, PHP dependencies were a curse. It didn't hurt anyone:

Notre prochain webinar

For a long time, PHP dependencies were a curse. It didn't hurt anyone: each project embeded its owns libraries, reinventing the wheel each time. Now, there is Pear/PECL for sharing libraries and modules, and PHAR, an archive file format. In one PHAR file, you can put distinct files, and PHP can use it as a folder or even access files inside it. There is compression option, too. The magic of PHAR is its header. You can put a shebang (#!/usr/bin/env php) and some code before the archive blob. Your PHAR can be an application, including all needed parts in one file, cross plateform. You just need a php-cli installed somewhere, and your PHAR file.

But.

The PHAR is painful to read, it can use ZIP or TAR container, and compress with ZIP or BZ2. Your application is now a blob. Trust me, I'm a blob. There is no cli to unphar your blob, you have to write some throwable PHP script to read the code.

Now, PHP applications are delivered as a PHAR, wget that ".io" ending URL and trust them. Don't care about trust, versionning or even signature, you never bath in the same river.

You are looking for sources? Composer is a tool used for fetching dependencies and building PHAR applications. Ok, I want to read its source, and build it. Composer use Composer to build itself. There no more bootstrap anywhere, you HAVE to download a blob somewhere on Internet. You need an egg to build a chicken.

You want to build a linux package? you know, the thing for deploying coherent version of an application, with its dependencies, and later upgrading. The application is opensource, but you have to download a blob, or building source with another blob. And you will sign this package, coming from somewhere. PHAR format handles checksum, but not signing.

Few package formats handle signature, but when the content of the package is a blob, the signature is mandatory.


Partager cet article :