On 03/09/16 11:20, Rowan Collins wrote: > On 3 September 2016 09:18:48 BST, Lester Caine <les...@lsces.co.uk> wrote: >> Is Composer really all there is? >> I'm looking at the problems projects like tiki have with trying to keep >> composer working in an active project, and other projects have just as >> many bug reports of composer having failed again! Keeping the right >> combination of versions of third party libraries may be what it is >> intended to do, but it does not seem to achieve it. > > Interesting, can you give any details of these problems? I've always found > composer to do its job very well indeed, and have heard nothing but good > things about it. I did a quick search for "tiki composer" and found a page > with lots of teething problems from 3 years ago, but I suspect many of those > are long since fixed. There's some interesting questions around how to use it > for optional plugins, which I hadn't thought about before, but PEAR doesn't > do anything to help there either, so not really relevant to this discussion.
https://sourceforge.net/p/tikiwiki/mailman/message/35331374/ >> warnings about "You are running composer with xdebug enabled. This >> has a major impact on runtime performance." > > So you don't like that the tool defaults to giving you a warning, which can > be suppressed, to explain why it might seem slow, due to a debugging tool > documented as not being suitable for production because it may have a > performance impact? I imagine PEAR runs slower as well, it just doesn't > default to telling you so. But being able to set up an environment where it is easy to switch tools on and off is being complicated by having to manage different 'composer' setups. Something which I don't think it was actually designed to handle? >> Trying to set up an >> environment where composer only exists for PHP7 so it does not affect >> the legacy systems seems equally problematic. > > Do you mean having a single codebase that can be installed with or without > composer? Mostly that's just a case of creating alternative autoloader / > bootstrap files, since all the code knows about composer at runtime is > "require 'vendor/autoload.php';" This is perhaps my sticking point. I have a perfectly stable framework without the need for any 'autoloader', and a folder structure that works. Reworking the whole framework so that it follows the 'vendor' rules while still also just working with bog standard require_once in the right place is where I keep coming unstuck. >> And Packagist has some >> many cross competing packages that it does not make providing a set of >> 'supported' php libraries at all feasible? > > There is some truth in this, pear.php.net was a curated package library, > whereas packagist.org is an open publishing platform. The problem is that for > something to be curated somebody has to spend time curating; mostly, the > people doing that right now are the big frameworks like Symfony, although > there are a few projects like PHP League. The idea behind PHP-FIG is also > relevant: rather than PEAR only allowing packages that follow a certain > style, users can see on an open market which packages advertise their > compatibility. I don't think the current PEAR suite will disappear since it does provide a clean set of tools, and probably at least 80% of legacy systems still rely on it. I've just been stung by 'mcrypt' not being available with a couple of the owncloud alternatives I tried. They will not install on PHP7, and I think I'm going to have to roll back to PHP5.x to get that working. >> If composer is to replace PEAR then it needs to be properly supported >> INSIDE PHP as PEAR is and give the sort of support that PEAR currently >> provides to new users. > > What kind of support are we talking about here? My experience of PEAR is > "pear install foo" and in composer that would be "composer require > somebody/foo", so I'm interested which scenarios you think need extra work. I WAS using SUSE's software management to keep all my production machines working cleanly. Currently that provides 5.6.9 along with every pear package I use. composer does not figure at all, but node, pip and bower all get support. Although I get the impression that a combination of npm with composer may be the way forward. npm can manage the development dependencies such as css tools as well as javascript management, but then do I actually need composer as well? Although I will ALWAYS prefer supplying the distributed library files I need from a local server rather than assuming they will remain available from some third party site, and it's that which I can't do with composer? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
