Why we use Composer for managing dependencies
Solving project dependencies for smart code reuse
One of our goals with Cumula is to make it easier to write web apps with less code. As part of this, we want to make it easy to use components written by anyone, and in the process keep the core of Cumula quite small. New services are launched every day and you should be able to add a new component to support that without upgrading your whole cumula installation.
With this in mind, we've published most of the service components in individual github repos. Composer answers the question, how should we (and you) manage getting the set of components and libraries your project needs installed and up-to-date as your project evolves?
A model for dependency management
In looking for a model to follow for managing project dependencies, we were motivated by NodeJS' npm and Python's pip/virtualenv. Luckily for us and continuing the spirit of reuse, PHP already has a dependency management project that has these same inspirations: Composer. In particular,
- Project-level dependencies, not system-level packages.
Composer installs dependencies in a project-local 'vendor' directory, providing an autoloader to use to get access to these packages. - Dependencies hosted in a central registry or from source/github.
In addition to the main "packagist.org" composer registry of packages, we can setup a Cumula-specific registry, you can setup a company-specific registry, or point directly to a git repo (where tags are used for versions). - A version-controllable, machine-writeable file for declaring project dependencies.
Each composer project has a single json file that lists its dependencies. - Good version range support for easily upgrading bugfixes.
Requirements can declare an open but limited range of versions e.g. ">=1.2.3,<1.3" - Automatically resolve dependencies of dependencies.
Each package has it's own list of dependencies, the full set gets installed when you run the "install" or "update" commands.
Building Cumula on Composer
Converting Cumula to be installable with Composer required very few changes beyond those we were already making to be PSR-0 compatible. Cumula had its own autoloader (and still does, but it’s responsible for much less now), so Cumula-based projects needed to switch to also use the generated Composer autoloader, and a few assumptions that Cumula’s internals made about where components were installed had to be loosened to support the structure of the vendor package directory.
If your project is already PSR-0 compliant and isn’t doing tricky library-discovery things in a custom autoloader, switching to use Composer should be as simple as adding a composer.json file declaring your code as a library.
Making use of Composer to install Cumula dependencies
Every Cumula-based application has a composer.json file that declares
- the repositories it uses (for git projects, this points to the public repo)
- and the versions of packages it requires from those repositories
See our post on adding the ViralHeat component for an example of adding a dependency to your project.
Looking ahead to making this even easier
Composer gives us all the tools to make this even more automatic in the future.
- Cumula will have a central public registry of components so that you don't need to point to each dependencies' github repo.
- The Admin component install process will grow to automatically add a to-be-installed component to your composer.json file and run the composer "update" command for you
[...] Why we use composer for manage dependencies [...]