Upgrading guzzle dependency to 2.8.*, fixes #70
Use guzzle/http instead of guzzle/guzzle, refs #70
merged branch BRMatt/upgrade-guzzle (PR #71)

Commits
-------

f8bcc3c Use guzzle/http instead of guzzle/guzzle, refs #70
244e4c2 Upgrading guzzle dependency to 2.8.*, fixes #70

Discussion
----------

Upgrading guzzle dependency to 2.8.*, fixes #70

Fixes #70

---------------------------------------------------------------------------

by fabpot at 2012-07-19T14:09:45Z

Would it be possible to switch to guzzle/http only instead of the full guzzle/guzzle package? What do you think @mtdowling

---------------------------------------------------------------------------

by stof at 2012-07-19T14:55:16Z

@fabpot apparently, ``guzzle/http`` depends on ``guzzle/common`` and ``guzzle/parser``, meaning you will still use the whole guzzle.

---------------------------------------------------------------------------

by mtdowling at 2012-07-19T15:32:24Z

Actually, switching to guzzle/http means you don't have to include the Guzzle/Service namespace. Seems like a good idea to me.

On Jul 19, 2012, at 7:55 AM, Christophe Coevoet<reply@reply.github.com> wrote:

> @fabpot apparently, ``guzzle/http`` depends on ``guzzle/common`` and ``guzzle/parser``, meaning you will still use the whole guzzle.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/fabpot/Goutte/pull/71#issuecomment-7100479

---------------------------------------------------------------------------

by stof at 2012-07-19T15:45:08Z

@mtdowling guzzle/service is not available as a separate package ?

---------------------------------------------------------------------------

by mtdowling at 2012-07-19T16:41:22Z

Right, because it would be redundant; a guzzle/service package would require everything, so I left it out.

On Jul 19, 2012, at 8:45 AM, Christophe Coevoet<reply@reply.github.com> wrote:

> @mtdowling guzzle/service is not available as a separate package ?
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/fabpot/Goutte/pull/71#issuecomment-7102007

---------------------------------------------------------------------------

by BRMatt at 2012-07-24T08:29:18Z

@fabpot Would you like me to update the PR to use guzzle/http?

---------------------------------------------------------------------------

by fabpot at 2012-07-24T08:35:27Z

If possible, yes. Thanks.

---------------------------------------------------------------------------

by BRMatt at 2012-07-24T16:03:32Z

@fabpot Pushed the change

---------------------------------------------------------------------------

by mtdowling at 2012-07-24T17:23:21Z

Do we need to ship the composer.lock file with Goutte? If I remember correctly, this has caused multiple issues in the past. What's the benefit of the composer.lock file vs well defined dependencies in composer.json?

---------------------------------------------------------------------------

by stof at 2012-07-24T17:35:53Z

@mtdowling shipping the lock file with goutte is useless IMO: it would only be used when installing the vendors in goutte, i.e. when running its testsuite, not when installing it as a dependency

---------------------------------------------------------------------------

by BRMatt at 2012-07-24T23:07:00Z

@stof Surely that's a good enough reason to commit a lock file? You want to ensure that everybody running the test suite is using the same environment. Having a well configured composer.json file (I assume you mean explicit versioning) isn't enough, as being too explicit can cause dependency hell when different gems require similar versions of the same dependencies, or as in this case, you need bugfixes found in the latest version of the package's dependencies.

The composer documentation also recommends committing the file.

---------------------------------------------------------------------------

by stof at 2012-07-24T23:10:01Z

@BRMatt if you lock the testsuite to an older version than the one selected by composer by default with your constraint, it means you are testing against a version different than the one used by your users.
And composer recommends to commit it for projects, where you indeed want to lock the vendors.