[Owncloud] Composer for PHP dependency management / untangling dependencies and license issues

Frank Karlitschek frank at owncloud.org
Sun Aug 18 14:30:00 UTC 2013


On 18.08.2013, at 16:03, Thomas Müller <thomas.mueller at tmit.eu> wrote:

> 
> Hey,
> 
> from my point of view we can use composer to build up the 3rdparty repo.
> I've been working on this as well:
> 
> https://github.com/owncloud/3rdparty/commits/with-composer-master
> 
> With such an approach we can update dependencies easier for sure.
> But I'd keep the 3rdparty repo in order to not break the dev setup (again)
> and to have a place where we store components which are not available via
> composer.

Yes. We have to keep it and we also have to use composer in a way that only clearly defined versions of the dependencies are fetched. If dependencies are constantly changing below our ass than this is a testing and QA nightmare.

We will also ship the 3rdparty folder including the dependencies in the releases.

Frank


> Regards,
> 
> Thomas
> 
> Am Sonntag, dem 18.08.2013 um 15:44 schrieb François Kooman:
>> Hi,
>> 
>> As an experiment I updated the user_oauth app 
>> (https://github.com/owncloud/apps/tree/master/user_oauth) to use 
>> Composer (http://getcomposer.org) to do the dependency management. It 
>> depends on the php-oauth-lib-rs library to validate tokens.
>> 
>> It uses the central "packagist.org" repository to resolve dependencies, 
>> although directly specifying Git repositories is also possible.
>> 
>> Running composer will install the dependencies in the "3rdparty" 
>> directory of the user_oauth module. The file for the module looks like this:
>> 
>> {
>>     "autoload": {
>>         "classmap": [
>>             "src/"
>>         ]
>>     },
>>     "config": {
>>         "vendor-dir": "3rdparty"
>>     },
>>     "require": {
>>         "fkooman/php-oauth-lib-rs": "0.1.*"
>>     }
>> }
>> 
>> It has some major advantages for dependency management, like for example 
>> the ability to show all used licenses by the dependencies, as an example 
>> my demo OAuth client application:
>> 
>> Name: fkooman/demo-oauth-app
>> Version: 1.0.0
>> Licenses: none
>> Dependencies:
>> 
>>   fkooman/guzzle-bearer-auth-plugin   0.2.1                MIT
>>   fkooman/php-oauth-client            dev-master 7f028ce   LGPL-3.0+
>>   guzzle/guzzle                       v3.7.2               MIT
>>   monolog/monolog                     1.5.0                MIT
>>   psr/log                             1.0.0                MIT
>>   symfony/event-dispatcher            v2.3.3               MIT
>> 
>> This makes it very easy to do license auditing. In addition it will take 
>> care of PSR-0, or classmap, as in the user_oauth case, autoloading of 
>> classes. There will no longer be a need to include the 3rdparty 
>> repository in Git as it will point at the "official" repositories. 
>> Making a release would just mean running "composer install" on the 
>> source tree and create a tarball with all the 3rdparty libraries included.
>> 
>> It would be a fun project to try to see if it is possible to create a 
>> composer file for ownCloud by checking the current dependencies and 
>> looking as to whether there is a "composerized" version of that library.
>> 
>> Regards,
>> François
>> 
>> 
>> 
>> _______________________________________________
>> Owncloud mailing list
>> Owncloud at kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud




More information about the Owncloud mailing list