Gentoo's "Composer Problem"

Image

Gentoo recently posted an entry in their blog describing the problems they are having with Composer as it relates to their distribution. Their issue basically boils down to the fact that they want to manage all installed software exclusively through their package managers. A single, central package manager allows security updates to be applied quickly, cleanly, and universally to all programs that depend on the affected package. Composer does not fit into this model; it pulls software from other sources, and beyond that, it manages the dependencies for every project independently. This results in multiple copies of the same package being installed on the system, complicating security updates.  While these issues are genuine, the solution Gentoo proposes is a little surprising. They say:

As long as the necessary require statements are left in the code (where they belong), we can ignore Composer entirely and install the package with the system package manager. We set PHP's include directory for our users, so require('Class.php'); already looks in the right place.

This proposal hinges on a rather improbable assumption: that, for the set of all PHP projects that a distribution may care to support, no two would ever choose to use the same descriptive symbolic name to describe entirely different class implementations with different APIs. For example, imagine you have two PHP libraries, one named Wisher and the other named Dreamer.  Both of these provide a class called Builder; \Wisher\Builder builds Wishes, and \Dreamer\Builder builds Dreams. When using an autoloader, the command new Builder() is seen by PHP as either new \Wisher\Builder() or as new \Dreamer\Builder(), as determined by the namespace of the file, or as stipulated by an accompanying use statement that identifies the namespace for that class. This means the autoloader has the information it needs to load the correct Builder.php file.

If these libraries were to follow the advice from the Gentoo project, though, and try to use a required statement to load the Builder.php file manually, then at most one of them could work on any one system. The required statement will load files either at an absolute path, or a path relative to the current working directory, or anywhere in the global PHP search path. It is this last item that Gentoo proposes to use to manage PHP library dependency files; however, this mechanism does not support multiple files with the same name and, therefore cannot be used in this scenario.

Many years ago, this sort of solution was considered viable. Either the Wisher or the Dreamer library would become popular enough to be used by some program that is bundled in a distribution. When it came time for the other to be added, someone would simply file a bug, “Dreamer does not work on Gentoo,” and the maintainer would pick another name for his builder class. Nowadays, though, the pace of software development of libraries managed by package managers far outpaces what the compiled binary distribution maintainers can keep up with. Small libraries pop up on a public source code repository site, get advertised in blogs, and mixed together in ways that the original authors never anticipated. It is a non-starter to presume that all of these projects must at all times use absolutely unique source file names.

It is true the Composer does introduce extra challenges, both for distribution maintainers and end-users alike. The extra complexity arose from the need to meet use cases born from the modern rapid development process. There is no doubt that there are still problems to overcome with these tools; however, ultimately, the solutions will come by improving the tool, not ignoring it.  In the end, it will be interesting to see which direction Gentoo and the other distributions go with respect to the inclusion or removal of popular projects that manage their dependencies by way of a language-specific dependency manager.