[Kolab-devel] PHP composer and packaging

[Thomas Brüderli]

Hello folks

With Roundcube, the Kolab Webadmin Panel, iRony and Synchroton, Kolab
has plenty of components aboard which are written in PHP. And obviously
not all of them re-invent the wheel and use external libraries to do
useful stuff. And, if you're familiar with PHP, you know about the lack
of a sophisticated package and dependency management in PHP.

There is (or used to be) PEAR to serve the purpose of a central package
repository. But unfortunately PEAR is slowly loosing its position and
the libraries get more and more outdated. This mainly because there's a
new star on the sky that obviously attracts PHP coders: composer [1].
Thus many library authors are now publishing their stuff at
packagist.org using composer and abandon their PEAR repositories. A
reason probably is that defining and maintaining composer packages is
much easier that PEAR and the direct interaction of composer/packagist
with SCM systems makes it even simpler to publish them.

So far so good. But a very important difference between composer and
PEAR is composer's design to operate locally on a project level and not
being a central library container. While web app developers are quite
happy with this approach as they can link different versions of a
library without braking anything else that's installed on the same host,
packagers and sysadmins raise their eyebrows looking at a maintenance
and security nightmare.

>From a developer's point of view, composer really is a useful tool and
that likely explains why lots of devs already moved to it. Besides
dependency management, installing and updating it also provides a snappy
autoloader which knows how to load the installed libs. We can finally
say goodbye to require, include and all the path tweaking hassle.

However, I can also understand the packager's concerns about various
aspects of composer and that its design makes it hard to integrate with
their distribution channels. But fact is that more and more PHP libs
will be published and linked with composer while PEAR is about to vanish.

So I'd like to discuss the possibilities around PHP development and
packaging with or without composer and what implication that will have
for both, development and packaging. As a result, we should define
policies how PHP-based projects define their dependencies and how those
are supposed to be packaged and distributed.

Of course we can "forbid" developers to use composer at all and to pull
copies of the 3rd party libs into the individual project trees. That
will result in self-contained packages but still leaves multiple copies
of the same library scattered around all over the place. Furthermore,
every project needs to implement the autoloading logic to use the libs.

With the recently added 'global' option [3] one can install composer
modules into a global location. But that option is actually meant to
have php-based CLI utilities installed globally but not for libs used by
some web application and it doesn't solve the autoloading issue right
away. And of course, the installation process still pulls the modules
from their online repositories and cannot operate from local sources.
But still this looks like a promising path to me and follows the idea of
PEAR. If we can define dependencies in a composer-like way instead of
maintaining (outdated) copies of 3rd party libs in our git repositories,
the devs are certainly happy. Then reading the composer.json files for
packaging and generating the necessary dependencies could at least be
given a thought. Now add some glue to allow autoloading classes from a
central php package location and we're fine.

Or we specify an entirely new way to define and handle PHP library
dependencies which can work for both development and distribution.

Does anybody have experience with this topic and or even found a nice
working solution how to deal with PHP packages? Please speak up!

Let's gather the options and stakes on this topic and find a sustainable
way for the ongoing Kolab development.

Kind regards,
Thomas


[1] https://getcomposer.org
[2] https://packagist.org
[3] https://getcomposer.org/doc/03-cli.md#global