On Wed, Sep 7, 2016 at 5:51 PM, Lester Caine <les...@lsces.co.uk> wrote: > On 07/09/16 10:58, Rowan Collins wrote:
> People who already know composer, as perhaps it's all they have ever > used, are at an advantage. I've tried a couple of times to pick up a > library that NOW has a composer option, Smarty is a case in point, but > IT'S use of composer forces changes to the style of working that are > then at odds with the rest of the framework. Yes over a few years I can > probably migrate, but this change is adding yet another layer of options > without any regard to interoperability. I can't apply a simple set of > rules and switch style as everybody else has their own style of using > composer? :( One point, pickle does not need composer to run. pickle install memcache will install the memcache extension (windows binaries, from pecl.php.net, etc) straight away. The composer integration allows to add extension dependencies and install them in one go using a composer install (or update). Also I have to state my opinion on this RFC. I am fine with any outcome. It would be nice to have for the extensions install especially as pecl does not support binaries nor VCS or any non pecl.php.net srcs (but downloaded.tgz).Both pickle and composer won't be more or less successful if they are or not part of the PHP releases. Also both pickle and composer are tools that can be used with PHP, HHVM or future compatible php implementations. They are not part of the php.net projects and will most likely never be. I also do not consider pecl.php.net as the main place where users can find extensions but github and in some extends bitbuckets. This is why I created pickle in the 1st place, to be able to do pickle install <some repo>/tag/whatever. The upcoming pickle packagist will simply the packagist.org pendant for PHP/HHVM/etc extensions, without any kind of releases being available but using the respective services. Install/Update can then either use the provided archives (they all provide archives) or install/update straight from git/svn or even cvs if some of us still have that internally. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
