Avoiding dependency hell

[joelwurtz]

Currently each adapter of php-http will have his own repository, i'm afraid to see a big complexity if some days an interface need to be changed and all adapter will then have to be updated and match against the new version.

My proposal is to have all the code / issue / ... on one repository and make sub view (like symfony with its components), so a PR for updating a interface will also contain the modification for all corresponding adapter / client.

[sagikazarmark]

Well, that's a point I haven't thought about so far. We could have an "adapter" package which contains all adapters, but I haven't done anything like that before.

One additional advantage I see is that this way adapters and tests can be in one repo (currently they are separated) and we can use behat. It has been a problem so far: how to use same behat tests for multiple repositories.

Anyone else? Ideas?

[hannesvdvreken]

You're talking about subsplit packages? Yes, that's a good idea, so that integration tests can reside in one repo, and all adapters can be installed separately.

In theory: good idea. In reality: could be a mess to setup. There are some tools out there to help us with that. https://github.com/dflydev/git-subsplit

[hannesvdvreken]

quick few extra questions:

• Hpw would you handle version numbers of the aggregated repository vs the separate adapter packages?
• What if we need to test both a Guzzle v5 and a Guzzle v6 adapter? Can't install both versions at the same time.

[sagikazarmark]

In theory: good idea. In reality: could be a mess to setup.

My concerns exactly.

Hpw would you handle version numbers of the aggregated repository vs the separate adapter packages?

I guess the separate adapters can have their own version number. Or versions could only be meaningful in the main repo, separated adapters would just follow it. Eg. changes in a few adapters. Release on the main package with a central changelog. Split and tag the same releases.

What if we need to test both a Guzzle v5 and a Guzzle v6 adapter? Can't install both versions at the same time.

That's a hard question. The only solutions I can think of:

• in cases like this the main adapter package holds only the latest version (like guzzle6), and the rest goes to a separate package (legacy?).
• another solution is that during testing, we add this into the build matrix, so that we can test against multiple versions (I think this is how it works in Ivory right now, but I am not sure)

[hannesvdvreken]

and the rest goes to a separate package (legacy?).

Ok for packages that officially deprecate their old major versions.

we add this into the build matrix

Imagine the build matrix with 4 PHP versions (5.5, 5.6, 7.0, HHVM), times 2 Guzzle versions, times 2 for lowest and highest. That's 16 entries in the matrix, very quickly.

[sagikazarmark]

Ok for packages that officially deprecate their old major versions.

But as far as I know, Guzzle 5 is still supported.

Imagine the build matrix with 4 PHP versions (5.5, 5.6, 7.0, HHVM), times 2 Guzzle versions, times 2 for lowest and highest. That's 16 entries in the matrix, very quickly.

I know, but I don't have any better ideas. Optionally we could run Guzzle5 tests only on 5.5, so that it only adds one extra build to the matrix.

[joelwurtz]

We could have the following workflow :

The master repository (i.e. php-http/php-http) is the reference for issue and source modification, namespace in the src will help to split into different repository :

• Http\Client -> php-http / client
• Http\Socket -> php-http / socket-client
• Http\Guzzle5 -> php-http / guzzle5-client
• Http\Guzzle6 -> php-http / guzzle6-client
• ....

Each of this namespace / repository have its own composer / test file (there is no composer.json at the root of the master repository).

The php-http master repository may have a tests directory for integration (but i dont think this will be necessary)

It will also have the .travis.yml where the test script will do the following thing :

• For each split
• cd into the directory
• composer install
• run tests

Then we can add a post test script which will update all the subtree split if the run is against the master branch

For the build matrix, we can also have the test script only running test for a specific repository given an env variable like :

matrix:
    include:
        - php: 5.6
          env: 
             - GUZZLE_VERSION=6.0
             - PHP_HTTP_TEST_REPOSITORY=php-http/guzzle6-client
        - php: 5.6
          env: 
             - GUZZLE_VERSION=6.1
             - PHP_HTTP_TEST_REPOSITORY=php-http/guzzle6-client

[joelwurtz]

Each repository will also have an override of the autoload provided by composer to use classes of php-http from the relative directory instead of the vendor one

[dbu]

i am actually -1 on this. my reason is that we need to strictly semver the interfaces anyways. the idea (at least to me) is that people can also write their own adapters or have their clients implement the interfaces directly. at that point we can't change interfaces without major version changes anymore.

having separate repositories that properly track which version of the client they support is not more effort than doing it all in the same. and the versioning of the adapters becomes a lot less confusing that way.

we could have a separate repository with the generic part of the adapter testing infrastructure. or put that test part into the utility repo if we separate it from the api repo.

[sagikazarmark]

Well, I see the point in the one repo and the separated repo solution as well. The question is that merging everything into one repo or having separate repos is easier to maintain and use. Also, the one repo solution comes with a few downsides (messed buildmatrix, directory structure, composer configurations and the subtree split itself).

[joelwurtz]

With more thinking, i think also there is more downsides than upside.

The dependancy tree should not be very complex, as each adapter / client will only depend on the master client (interface) there should be no interaction between them (or very limited)

[hannesvdvreken]

Dependency graph should be like this:

(from this blog post: http://blog.madewithlove.be/post/http-client-for-sdks/)

[hannesvdvreken]

All arrows go up, as they only depend on more stable packages, or higher level abstractions.

[joelwurtz]

And, if i'm correct, with the current terminology branch adapter-client no longer exists (adapter is replace by client)

[sagikazarmark]

Adapter client originally implemeted HttpMethodsClient and accepted an Adapter. It could still be implemented. However I would rather replace it in the dependency tree with methods-client-implementation.