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

[Frank Karlitschek]

On 18.08.2013, at 18:16, Andreas Fischer <bantu at owncloud.com> wrote:

> On 18/08/13 16:30, Frank Karlitschek wrote:
>> 
>> 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.
> 
> This is how composer is designed. The composer.json[0] defines what you depend on (e.g. "phpunit/phpunit": "3.7.*"), then on "composer update" specific versions are locked via the composer.lock[1] file (e.g. PHPUnit 3.7.22). On "composer install" dependencies are installed according to the .lock file.
> 
> Also, ideally, ownCloud would have good enough code coverage making it much easier to jump from one minor version of a dependency to the next using composer update (e.g. "composer update phpunit/phpunit").

sure. But in reality we already have more than enough challenges with proper QA and testing. So randomly changing and updating dependencies will make things harder and not easier :-)




> 
> [0] https://github.com/phpbb/phpbb3/blob/develop/phpBB/composer.json
> [1] https://github.com/phpbb/phpbb3/blob/develop/phpBB/composer.lock
> 
>> 
>> We will also ship the 3rdparty folder including the dependencies in the releases.
> 
> See [2] for how we do this in phpBB.
> 
> [2] https://github.com/phpbb/phpbb3/blob/develop/build/build.xml#L172
> 
>> 
>> Frank
> 
> Cheers,
> Andreas
> 
>> 
>> 
>>> 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
>> 
>> _______________________________________________
>> 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