On 18/08/13 16:30, Frank Karlitschek wrote:
On 18.08.2013, at 16:03, Thomas Müller <[email protected]> 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").
[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
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
