2016-09-07 11:33 GMT+02:00 Lester Caine <les...@lsces.co.uk>:
> 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
If someone replaces it by mistake, you should have a version control system
that
allows reverting that change. You're fine then.
> or when an update picks
> up a change to a package that was not actually the one expected.
If a vendor doesn't follow semver, you can pin specific versions at any
time and only
update the constraint manually and run composer update afterwards.
> 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.
>
That's entirely different. If dependencies change, you clearly see a
changed composer.lock
in your version control system history.
> 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.
>
If you commit your composer.lock file, composer install will install just
the same dependency
versions you have locally installed on your development system. There's no
difference between
development dependencies and production dependencies, apart from
require-dev, which you might
want to skip on production.
> 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.
>
There's a getting started guide and enough documentation available for
Composer.
https://getcomposer.org/
Regards, Niklas
> But I know the answer already ... not our problem :(
>
> --
> 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
>
>
