Composer vs. Linux Distributions: A Mental Model Battle

Recently, Gentoo documented what they view as the Composer Problem: Basically, PHP projects using Composer can't be packaged the way they want to package it, with system-level shared libraries. This is not a new complaint; Other distributions have complained about Composer's impact before. But fundamentally I think the issue stems from having the wrong mental model of how modern PHP works when viewed from a distribution or sysadmin perspective.

In a recent heated GitHub thread, several people referred to PHP "linking" to 3rd party libraries, as if they were shared C libraries. That is simply not the case.

Neither "static linking" nor "dynamic linking" really applies to PHP. From a sysadmin perspective, PHP is closer to highly complicated bash scripts than anything else. However, since the terminology has already been used I will continue with it.

A bit of history: In the BC era (Before Composer), there were two ways that PHP developers used 3rd party code:

1. Copy and paste from a blog post into your own repository. This is the "statically linked" approach.
2. Use PEAR, which was installed globally on the system. This is the "dynamically linked" approach.

Both of these approaches had issues, but PEAR had far more. Basically, PEAR sucked balls for anyone who didn't have root on their server, which for PHP devs was the 95% use case. It was hard to use, hard to contribute to, and if you depended on a version of a package that wasn't what was pre-installed, or was different than some other application on the same server needed, you were SOL. Basically it was unusable for the majority of the market.

And then there were manual require statements, which Gentoo is asking PHP developers to go back to. Those suck. Period. Full stop. Telling PHP devs to go back to PHP 4-era manual require statements is akin to telling them they need to cut off their thumbs to type and must use a 386 computer at the latest, while sitting in a dark room whose only lightbulb is pointed straight in their eyes. No, really, we're a decade past that era and it is not going to come back, ever. For a distribution to even make the request is bordering on offensive.

What Composer did was make approach 1 ("static linking") far easier and more sane. It did NOT address the system-wide-library question; in fact, the net result has been that the PHP community has entirely abandoned the "dynamic linking" approach wholesale, and has been much happier for it. Although PHP is runtime interpreted, modern PHP really doesn't function without compiling an autoloader for locally-available files.

Let me repeat that, because it's the crux of the disagreement: From a sysadmin/distribution maintainer point of view, composer is the compile step of PHP and only supports static linking.

Once viewed that way, the situation becomes much more obvious. The directory in which composer install is run is equivalent to the "static binary" of a compiled language. Or to a directory tree of .class files for Java.

Of course, PHP is not the only language to take that approach. Go, for instance, is only statically linked. Shared system-level libraries are just not a thing in Go, by design, and it gets by just fine, and distributions manage to ship Go packages just fine.

What that means for distribution packagers is this:

1. For PHP apps that are frameworky in nature, or intended to have the end user add/remove add-on packages (Symfony, Zend Framework, Drupal, Laravel, etc.)... please ignore us. DO NOT try to package these. Please. We don't want you to. We got this. Just ignore them and we'll all be fine.
2. For PHP apps that are a complete bespoke system (PhpMyAdmin, Wallabag, etc.), treat composer install the same way you would make or javac or go build.

That is, for a "binary" distribution (RedHat, Debian, Ubuntu, etc.), run this:

composer create-project wallabag/wallabag wallabag --no-dev --optimize-autoload

And then treat the resulting "wallabag" directory as a binary. Tarball it, package it, have a nice day. If later the project updates its dependencies due to security releases... recreate the "binary" and package that up. Or if one of its dependent packages has a security update that doesn't cause wallabag to update its own version, the distro can recompile itself and release a 1.2.3-1distroname version, as they already do for hundreds of packages.

For a "source" distribution (Gentoo, Arch, etc.), the "source" package is... probably just that composer create-project command, I wager. So when a user installs that package, the "compile" step runs that command and "compiles" their application, downloading the appropriate packages. If they want to recompile later, that's no different than recompiling a Go app.

The mistake here is trying to treat dependent packages of modern PHP applications like shared libraries. They're not. The community has spoken, and PHP simply doesn't work that way anymore. Fighting that is a losing battle. But by viewing composer as a compiler, distributions can still slot PHP into their typical workflows and get all of the security update ease that they're looking for.

At which point the only remaining objection is disk space usage. The answer on this front is simple: It's 2016. I can buy a 3 TB hard drive for under $100 after shipping. Your point is invalid.