Provide psr/http-client-implementation in composer.json

[powli]

Q	A
Bug?	maybe
New Feature?	maybe
Version	1.2.0

Actual Behavior

Package does provide only php-http/client-implementation

Expected Behavior

Package should also provide psr/http-client-implementation if fully compatible with PSR-18

Steps to Reproduce

Create a project with composer.json:

...
"require": {
        "psr/http-client": "^1.0.0",
        "psr/http-client-implementation": "^1.0.0",
        "psr/http-message": "^1.0.0",
        "psr/http-message-implementation": "^1.0.0",
        "psr/http-factory": "^1.0.0",
        "psr/http-factory-implementation": "^1.0.0",
},
"require-dev": {
        "phpunit/phpunit": "^6.0.0",
        "nyholm/psr7": "^1.0.0",
        "php-http/mock-client": "^1.2.0"
},
...

Composer install/update will fail with Your requirements could not be resolved to an installable set of packages. where it would succeed if I'd require php-http/client-implementation instead.

Possible Solutions

Add psr/http-client-implementation to composer.json provides section.

[xabbuh]

So far this looks expected to me. The Client class does implement the HttpClient interface only and this interface is only PSR-18 compatible if HTTPlug 2 is installed (but the mock client works with HTTPlug 1 too).

[dbu]

i agree with xabbuh on this. anyways it feels dangerous when this package "provides" the client implementation - a real project should always also have an actual implementation and only use the mock client for testing.

or am i missing a use case here? i guess libraries with no functional tests would be one... but until we require httplug 2 we should not claim that we are psr-18 when we can't guarantee that.

[powli]

I have to agree, I was missing the hold compatibility with HTTPlug 1. So maybe a version 2.0 that only depends on HTTPlung 2 would make sense.

or am i missing a use case here? i guess libraries with no functional tests would be one... but until we require httplug 2 we should not claim that we are psr-18 when we can't guarantee that.

That's in fact exactly our use case. We have a library and just want to say: 'Throw any compatible client into the project and it will work'. For tests we only use recorded requests/responses from the wrapped API.

[dbu]

i added this to #34

there are however no immediate plans to go release mock client 2.0. if you want to do a pull request against the branch we use in #34 i can see moving this forward however. the mock-client seems reasonably stable, version 1 will remain just usable for existing libraries that still allow httplug 1.

[dbu]

this will happen in version 2, with #34