On Wed, Apr 9, 2014 at 9:08 AM, M. Dekker <menno.dekker@erasmusmc.nl> wrote:

In general I like the idea of composer and I have played with it a little in the past.


What I really like about what happened after we moved to github is that it is much easier for people to help us develop limesurvey. My biggest fear with moving to composer is that is will be more difficult for people to check out the code from github and get it running.


Valid argument; there are several ways to mitigate this. One of them would be a simple initialization script, that will allow users to just run 1 extra command to get it all up and running. 
Further note that these are developers, who are generally more tech savvy than users.

My IDE of choice Netbeans has support for composer so that will be easy for me. Maybe my concern with it being more diffult is nothing but a 'feeling from the past'.


In subversion we have externals, but reading a little about submodules in git I think that will only be more difficult.

I don't really see how the framework can be installed using composer and I fear that switching techniques draws focus from development to getting it running again.

Do you mean if limesurvey can be installed using composer? Because that is not so much my goal. I want our zipped downloads to contain all we need, just like it does now. The only difference would be for us, the devs. 


I think that updating versions without knowing what they do is dangerous, especially with a large userbase like LimeSurvey has. So the update still needs to be a handmade decision I think. I don't see a big benefit in moving to composer, but on the other hand I don't have much against it either.

Yes that is how it works anyway, the composer.lock gets committed along with the composer.json file. This ensures each  developer gets the exact same version of all dependencies. However updating within minor versions is as simple as running composer update (and then doing some tests to see if it still works of course).



From: Sam Mousa [mailto:sam@mousa.nl]
Sent: woensdag 9 april 2014 00:45
To: limesurvey-developers@lists.sourceforge.net
Subject: [limesurvey-developers] Using Composer to manage dependencies in 2.06.


Hi all,


For 2.06 I'd like to switch to using composer to manage our dependencies on third party packages.


I'll try to list some of the pros and cons of using composer vs using nothing.



- One location for all third party php code. (Currently we have most of it in application/third_party, but some Yii extensions are in application/extensions)

- No more importing for third party code, Composer creates an autoloader for all installed dependencies.

- Smaller repository size.

- Cleaner commit history (an upgrade of Yii will show a 1 line change in composer.json instead of a 100 file change).

- Easier way to upgrade dependencies, no longer finding out where they came from and downloading a zip file.

- Can automatically download dependencies after each git pull via post-merge hook.

- Better dependency control, we can require a version range thereby allowing us to get updates of dependencies as long as they dont break compatibility.



1. When you initially clone the repository you will have to run composer install (and add the post-merge hook for auto updating.

2. The build server will need to use composer to get the appropriate depedencies.



Composer (www.getcomposer.org) has been gaining a lot of traction amongst many different PHP frameworks and CMSes.


If you want to checkout how it would work for you as a developer you can do the following:

1. Clone limesurvey repository (this is my fork which uses composer)

2. Go into limesurvey directory

cd LimeSurvey

2. Get composer:

php -r "readfile('https://getcomposer.org/installer');" | php

4. Install dependencies

php composer.phar install


Optionally you can run composer install automatically after each git merge (git pull also calls git merge) by adding a post-merge hook. 



If we decide to use composer we could add a simple  script that initializes the hooks.


Please let me know your thoughts and opinions. Also if you feel I have left out any pros or cons list them so we can make an informed decision.






Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
limesurvey-developers mailing list