Michael Prasuhn recently sent out a tweet regarding Composer vs Drush Make:
In the brief discussion that ensued on that thread, it was pointed out that Composer and Drush Make are fairly similar in terms of feature parity; however, there remain some differences between them, and the topic of the pros and cons thereof is more complicated than the 140-character limit of Twitter allows. I therefore decided to explain the current differences between these two options.
If you are not familiar with Composer yet, see the Composer Tools and Frameworks for Drupal presentation that Doug Dobrzyncski and I did for DrupalCon LA. It’s easy to get started quickly with Composer today with starter projects such as example-drupal7-circle-composer and example-drupal7-travis-composer—but is Composer right for your project? Let’s examine some of its strengths and weaknesses:
Recursive Dependency Management
Composer is, first and foremost, a dependency manager. Each dependency that a project requires can itself declare what its dependencies are; if multiple libraries require the same thing, but specify different sets of versions that they work with, Composer will analyze the whole dependency tree and either pick a compatible version, or explain which components do not work together. While Drush Make does allow for recursive make files, no analysis of the dependency tree is done.
Composer’s dependency manager is a point in favor of Composer for projects that need to make use of php libraries outside of the Drupal ecosystem of modules and themes.
Generation of the Autoload File
One of the best features of Composer is the autoload.php file that it creates during every install or update operation. The autoload function allows php code to instantiate instances of classes without having to know where the source code for each class is located. Autoloading is a built-in feature of php, and is available to Drush Make users through the xautoload module; with Composer, it’s built in, and covers code that is not part of any Drupal module.
Composer’s handling of the autoload file is a benefit for projects that want to use object-oriented php code.
Recording the Exact Components Used in a Build
Composer has a file called composer.lock that records the exact version of each component that was selected in the most recent build. The components listed in the composer.json file can either be locked to a single version, or can be allowed to be updated when new versions are available.
With Drush Make, in order to capture the exact version of each component used in the bulid, you must specify the exact version to use in the make file itself. What people usually do to update a make file is use drush pm-update, which itself has a locking function, if it is needed.
Update: Drush 7 added a feature to Drush Make that allows you to generate a locked makefile, with all versions resolved. With this feature, you need to generate your lock file as the first step, whenever you want to update your dependencies; thereafter, you simply build with the lock file as the source makefile instead of the original file.
So, Make has feature parity with Composer for this function, as long as you are aware of the correct workflow to use with Make. With Composer, the default behavior is to only update when specifically instructed, whereas Make will update every time unless you explicitly use the lock file feature.
The Perfect Website Launch
Patching and External Libraries
Composer has feature parity with Drush Make for patching and external library use, but you have to know which plugins to use.
The biggest advantage that Drush Make has is its maturity. Since it has been in use for so long, and is based directly on the releases repository maintained on drupal.org, and is itself used in the drupal.org profile packaging system on drupal.org, you won’t need to think twice about the availability of and module that you want to use. Composer users have packagist.drupal-composer.org at their disposal, which contains Composer packages for all drupal.org projects with tagged releases. Minor road-bumps may be encountered here and there; some projects might not exist yet on drupal.org or packagist.drupal.org, or a Drush extension might be mis-labeled as a Drupal module in packagist.drupal-composer.org. These sorts of problems are resolvable, but might cause a little extra head-scratching for new users. As Composer adoption increases, these situations will be found, reported and fixed at a greater rate.
Drush Make is more mature than Composer, but Composer is still very usable today.
So, which one should you use? It is going to depend on which factors are most important to your project. Here's the scorecard from our comparison:
|Recording Build Components|
|Patching and External Libraries|
Both are powerful tools that have all of the capabilities needed to get the job done; Composer is stronger in the area of modern features, while Drush Make currently has the most mindshare among projects within the Drupal ecosystem.
Drush Make has served a lot of projects well for a long time, and there certainly is no need to switch maintenance projects over to Composer. Composer is a mature and standard tool in the broader php community, though, and the Drupal community would be well served by adopting it as well over time. Composer has achieved feature parity with Drush Make, and is more modern, more standard, and more convenient. Projects that are under active development using object-oriented code or external php libraries would be well served by a switch to composer today.Topics: Drupal Planet, Drupal