On 07/09/2016 11:33, Lester Caine wrote:
On 07/09/16 09:10, Ferenc Kovacs wrote:
I can only report what I have read in various newsgroups and forums, and
they have said that composer has screwed up their installations. If it is
capable of doing that then it is a serious issue that needs addressing.
you can, but you shouldn't spread FUD but do your own research.
composer will only do something when you execute it, without providing any
actual problem, there is no way those could be refuted (FUD), and brings
nothing to the discussion.
what you have probably seen is people not using the tool properly
from my experience people usually screw 2 things up:
1. executing "composer update" without any arguments which will update
every package listed in your composer.json file to the latest version
allowed by the version constraints
2. not putting the composer.lock under version control and then being
surprised that the other developer who makes a "composer install" from
composer.json can have different(eg. more recent) versions installed
This does highlight the different approach to handling things in a
production environment over a development one. The problems I have seen
IS when composer.lock gets replaced by mistake, or when an update picks
up a change to a package that was not actually the one expected. Running
around then like headless chicks trying to work out what is wrong is
much like the problems when a hosting site simply switches from PHP5.3
to 5.4 without warning.
composer.lock is supposed to be version controlled, so figuring out
which package have been updated should not be a problem. besides, if you
don't run "composer install" the package aren't going to be updated. but
when you do, you will see which packages are update.
even if you run "composer update" without an argument, it should only
update packages to "semver compatible" version of those package unless
the version constraints have been manually entered to allow major
version upgrade. obviously some package releases don't respect semver
(either by ignorance/choice or because there is an unknown bug)
if you deploy an updated composer.lock in production and that it
upgrades your dependencies. that means that it passes code review, CI
and staging or that you don't do any of those. I don't think composer
should be blamed for that
I can see that composer has a place in a development environment and
developers will be more than happy playing with that, running the right
command line steps and keeping their set of composer controlled
libraries up to date. The problem comes when 'publishing' a version of a
project and ensuring that the production hosting has the right setup.
The web based tools built into a distribution process will need to be
able to educate users who have been happy with PEAR into the new style
of working and it's that layer that needs to be at least prototyped
before current functional systems are switched off.
"current functional systems are switched off." => this is not what is
being proposed by the rfc!
the first potential vote is "Deprecate pear/pecl & unbundle in 8.0" if
it passes, it means it won't be bundle with PHP and it will probably
stopped being referenced in the documentation. but it will keep working,
that's very different from "switched off"
But I know the answer already ... not our problem :(
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
