Add Composer installation support #10

wants to merge 17 commits into

Composer is the new emerging default way of handling PHP library dependencies. This patch adds support for it that works very similarly to the NPM support in the Node.js buildpack: if there is a composer.json file in an app, then its dependencies are installed with Composer.

Here is a simple example app using it: (source code)


Shouldn't it verify that "vendor" does not exist in case you shipped the vendors in the package?

@beberlei beberlei and 1 other commented on an outdated diff May 8, 2012
@@ -46,6 +46,20 @@ cp $LP_DIR/conf/php.ini php
mkdir -p bin
ln -s /app/php/bin/php bin/php
+# check if we have Composer dependencies and vendors are not bundled
+if if [ -f composer.json ] && [ ! -d vendor ]; then
beberlei May 8, 2012

sorry to annoy, but wasnt this www/composer.json before? :), since you invoke composer from www also.


Two questions:

  1. Is www the public directory on heroku? Is there no way to do this in a directory not exposed to the world?
  2. Can you check if a composer.phar is shipped with the code and use that instead (and not delete it)?


  1. I didn't want to make too big changes to how the PHP buildpack works, so yes, this is the public dir. Feel free to submit a PR doing a nicer organization :-)

  2. I could check it, but how likely is that? Is there a good reason to keep an instance of Composer in your own app repository?



I think it's very likely since composer is in an early state. I distribute the phar with all my projects to avoid always going through changes. I update every once in a while though. But e.g. my php_composer resource for chef currently assumes composer.phar in the project as well.

Add to that – it also minimizes the RTs required for an install. And one less dependency on external resources and Internet.


@bergie nice, i wonder for sf2 apps, one would need to have things stored under another root project and root/web for public folder. It would be the only thing preventing us from deploying sf2 apps into heroku right?

keeping composer.phar is not a good idea, composer is fetched with the curl or so command on but it should be done automatically within this package too.


What do you guys do when is down? Don't deploy anymore? :)


you fork your own, put composer.phar on it and run it


The PHP buildpack currently caches everything that it needs in S3. I suspect that this is a wise policy that should be continued, instead of relying on — which would be the first "external" dependency in the whole buildpack, if this pull request were accepted verbatim, I believe?


@brandon-rhodes we can easily place a local copy of composer.phar to this if needed. Then this would be sort of similar to the Node.js buildpack, which does include NPM.


Bump 👍


When experimenting with this using a standard Symfony2 app I'm getting the error below:

Generating autoload files
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap handling the post-install-cmd event terminated with an exception

The php executable could not be found, add it to your PATH environment variable and try again

I've tried augmenting the path to include the php binary like this:

  export PATH

... to no avail. Any suggestions?


@friism I guess it makes sense


I'm using a different web root for my src so there is no index.php file in the root. However, I still need composer to run to install the dependencies. It seems like the detect script should look for an index.php file OR a composer.json file.


Any updates on this pull request. Composer support by default would be awesome...



buzzedword and others added some commits May 30, 2013
@buzzedword buzzedword Update compile
Cleanup after install to make sure no module has a repository left, reducing slug size.

This is re-run every deploy, so these directories are being nuked every time anyway. Might as well save space.
@bergie bergie Merge pull request #2 from buzzedword/patch-1
Update compile

Can this be merged? Would be nice to not have to rebase composer support...


For the record, it appears that the dynamic linking of mcrypt breaks this pretty awesomely:

/tmp/build_2qch10sfzpchy/php/bin/php: error while loading shared libraries: cannot open shared object file: No such file or directory

The following is a potential fix, though still buggy because of .so loading errors:

LD_LIBRARY_PATH=$BUILD_DIR/php/ext:$BUILD_DIR/vendor/mcrypt/lib $BUILD_DIR/php/bin/php -c $LP_DIR/conf/php.ini -d detect_unicode=Off composer.phar install --prefer-source

You'll notice I added -d detect_unicode=Off as well as :$BUILD_DIR/vendor/mcrypt/lib to the LD_LIBRARY_PATH.


Is there any possibility of Composer being added to the native PHP buildpack in the near future?




Best PHP buildpack so far is this one:


+1 @willdurand I've been using (and trying to contribute) to that one for a while. It appears there is less support for PHP than for other official heroku buildpacks - based on recent contributions - which sucks but I can totally understand. is legit. A++ would deploy again.


Two years, no progress. What is going on over here?


Unfortunately it looks like PHP is a second-class citizen in Heroku land. Thankfully, the guys over at aTech Media are launching their own cloud hosting platform, Viaduct, which has PHP support from the get-go, so I’ll be investigating that as soon as it launches.


Well, they hired @dzuelke for improving PHP support, so things should be better at some point.


Indeed; expect official support to be shipped in early 2014. Composer support is obviously very high up on the list of priorities.


@dzuelke Glad to hear and to have some sort of timeline. Looking forward to seeing it.


@martinbean There's also going to be some sort of roadmap as well as more regular announcements in January.

@hinaloe hinaloe pushed a commit to hinaloe/heroku-buildpack-php that referenced this pull request Mar 13, 2014
@iphoting iphoting Nginx version: 1.2.6.
Resolves #10.

@dzuelke hi david. when can we expect composer support exactly? are there now any more information on this?


Well, Viaduct has launched their beta, with PHP support from the off, and even Composer support. Once I’m comfortable with Viaduct, I’ll be moving all my apps from Heroku to there.


The best PHP buildpack was made by awesome @CHH


@bytefreak @martinbean @acedude Email me (dz@) and I'll get you early access to the new PHP support.


I think I emailed the right place. I'll be very excited to test it out and blog about it when it's ready.


hi @dzuelke. i didn't receive anything.


Invites are going out tomorrow, @bytefreak


Composer is now supported in the new version of PHP support on Heroku. Check out the blog post and the Dev Center category with the Getting Started Guide and other resources!

@dzuelke dzuelke closed this Apr 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment