On 09/08/16 06:54, Sara Golemon wrote: > On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine <les...@lsces.co.uk> wrote: >>> That is, when I'm running the test-suite of my package, the Composer >>> project is the root folder of that package - but when the package is >>> being consumed by another project, it's installed in a sub-folder in >>> that project's "vendor" folder. >> >> So Composer IS now the rule rather than some optional extra? >> > Yes, the community has decided that for us. Or at least, Composer is > a *significant* player in the ecosystem of PHP development. > require_once() might be fine for NiH applications, but for the > collaborative world of modern PHP, it's the defacto standard.
Much as PSR also does. This is probably fine if one is starting a project from scratch, but with now 15+ years worth of code that does not follow this 'modern style' it's another barrier to moving code forward. There is nothing wrong with the code other than newer users done approve of the style of working :( >> It is OK >> for users who only want to load the one application, but when one is >> running a large number of different packages it's a major hindrance. >> > You'll need to back that up with some more detail. Composer is > specifically designed to _compose_ through multiple packages and also > allows for isolation when that sort of blending doesn't make sense. > Far from a hinderance. Several packages that I have been trying to update have said that it's better NOT to use composer if you need to maintain a legacy view in addition to the newer code. Certainly having to keep different installs of PHP with different structures does not help the development process. It's bad enough running PHP5.4, 5.6 and 7 in parallel without also changing the framework as well. >> I don't need to know where my Linux install has put the include files ... >> it takes care of that and then finding the pigging things again is the >> problem. >> > So, autotools and cmake and the like exist for what purpose then? > Even pkg-config, which was supposed to solve much of this problem is > incomplete, at least on GNU distributions, falls short. There is not a 'single solution' that will fit the vast range of users of PHP but current targeting seems to be aimed at a subset of both coding style and practice at the expense of perfectly safe and functional existing code. >> Much the same with finding the source of problems in the mess >> that composer has created! >> > [citation required] I need to find the write-up on that. It was a well laid out blog on why pdt/eclipse had problems with the composer approach to managing legacy code. -- 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
