On 09/09/16 11:55, Ferenc Kovacs wrote: >> Most sites will skip whole major versions of updates simply >> becuase their production system IS working ... > > usually it is easier to migrate in multiple smaller steps, but of course > there are people who will do the one big upgrade.
Many of the sites I work on had not managed to complete testing and re-writing of systems for W7 when XP was end of lifed. So XP is still running on critical systems. The work done to move to W7 fails again on W10 so once again the whole process has to be repeated. My PHP code running on those sites goes back to the late 1990's and is still doing the job it needs to do. The problem with 'smaller steps' is you need to have the resources to complete on step before the next one rolls up, and in the 'bad old days' when PHP fixes were slow to appear it WAS possible to keep up. Today PHP5.3->4 is STILL a hold up for these sites when there are so many other updates to keep track of. If I could wave a magic wand and every legacy system just worked on the next 'small step' ... >> Back to PEAR ... what happens if I simply install a copy of composer >> centrally and rename it 'PEAR'. composer.phar simply gets installed >> centrally and any new tech has access without having to install their >> own copy. > > as I and others mentioned before composer does user/system wide > installations: https://getcomposer.org/doc/03-cli.md#global but not sure > what do you mean renaming it to PEAR, they have different command line > format, etc. you can't just rename it and expect it to work. As I said elsewhere ... just the idea that installing PHP_CodeSniffer and similar tools in the same central manor that PEAR makes them available could be an alternative base. >> As with Git/Hg users can have their own play areas USING >> composer, but to be honest from a safety point of view one knows that >> the version of composer being run has not been infected with some >> injection mechanism. We keep going on about validating the PHP code >> against malicious attack, but the whole framework is open to that? > > not sure I follow what are you trying to say here, so from the past your > devs were not allowed to add new PEAR dependencies, but someone else did > that for them? and now you are afraid that if you introduce composer they > will install random packages they will introduce something malicious? > First, if adding PEAR packages was a burden in the past, I'm fairly sure > that you have a couple of PEAR packages just manually committed to you > repository as part of your project. > with composer you don't push your dependencies to your repository, but with > the composer.lock you can guarantee that installing the dependencies will > be reproducible and you can scan/review your dependencies either > periodically or on-demand when your composer.lock has been changed. > also, if you want, you can opt-out from using https://packagist.org/ and > either explicitly use git trusted git repositories as package source, or > even use your own trusted mirrors. > but this isn't a topic for internals@, but more suited for > https://groups.google.com/forum/#!forum/composer-users That a user can 'just install' their own copy of something is the problem once one moves to the production environment. And yes just adding or updating any library to a production system needs to be properly managed. If the default installation of PHP provides for a default way of adding extensions and user land code it should be to the default installation of PHP. Off the shelf, composer is not following that model even for the initial installation of the code, so is out of sync with the CURRENT installation model of PHP. Now the current model may well be old fashioned, but there is no clear alternative to replace it, so if an element of that model such as PEAR needs to be replaced with an alternative such as composer, the alternative should be used in a manor that fits the overall installation model? Now if there is a more modern installation model which better fits the way composer sees the world, then the whole installation process should be changed to that? -- 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
