-s composer package input

State: testing

The composer source package fetches composer bundles. It can either turn them into system packages (deb/rpm), or even phar archives.

Normally you wouldn't use this approach for project management. It's intended for fixating dependencies as globally shared libraries. Having php includes under system control sometimes simplifies deployment.

Per default system packages extract their payloads under /usr/share/php/vendor/.

Pack individual components

To package a dependency of a composer checkout use:

xpm  -s composer  -t deb,rpm  gregwar/formidable

Note that fpm/xpm is meant fro creating one package at a time. So this will output one *.deb and/or *.rpm package.

You can't specify multiple composer bundles as input files right away. (They would end up intermixed.)

Pack all the things

However it's just as trivial to covert all composer dependencies at once with a shell loop:

for P in vendor/*/*; do
   xpm  -s composer  -t deb  $P
done

That will create a bunch of php-composer-vnd-pkg_0.1_all.deb system packages.

Fetch afresh

If you're not within a composer-managed project direcory, then the -s composer hook will of course fetch it freshly via composer/from packagist. You can predefine a version as well:

xpm -s composer -t deb --composer-ver 2.7  new/new

This will again just package this individual bundle. It will have its system Depends: field populated. But its actual dependent packages must be crafted this way too/manually.

Packging phars

If instead of a system package (-t deb and -t rpm) you just want to create Phar archives of vnd-pkg.phar, then use the -t phar target:

xpm -s composer -t phar  vendor/vnd/pkg

Such phar archives of course won't contain absolute paths. In fact all source files are assembled without any ./vnd/pkg/ prefixes. → That would be redundant because it's all already obvious from the phar basename.

Using phar packages within projects of course requires a modern autoloader. Be advised that it's a super negligible performance benefit by itself. Generally classmap-based autoloaders can occassionally be faster. But if class dependencies are dispersed across files within, then there's little gain over entirely file-by-file-tapping ones.

Phars in system packages

An interesting variation for the packaging process is to convert Composer bundles into Phars and then into system packages. (This is labeled "matroska" mode in the plugin). It's easy to achieve with an extra --composer-phar flag:

xpm -s composer --composer-phar -t deb,rpm  new/new

This way you'll end up with a system php-phar-vnd-pkg_0.1_all.deb/.rpm package. That would install its contained vnd-pkg.phar directly under /usr/share/php.

Again you'd need an autoloader that's designed for this. See shared.phar for a prototype. (A system trigger will keep the global map updated.)

Phar options

In either case the -t phar module is used for generation. Currently and per default the composer source hook predefines the Phar format to be of the ZIP+gz variaty. You can set the --phar-format=phar+gz for a native Phar alternatively of course.

Alternatives

If you're just looking for a way to bundle up all project dependencies at once, then also check out github:clue/phar-composer. It was designed for that, is implemented in PHP, and provides more targetted options.

Distinct -u composer update filter

Note that the -s composer source plugin is orthogonal to the -u composer filter. The update filter only generates a stub composer.json ans is intended for plain phar archives generated from -s dir source files.

So you don't usually want to combine them.