This habit originates from Symfony, and I don't really know the reason. They are hard to maintain and adds no real value

Version 1.7.2

It seems #154 broke something, because I now got the following error:

No PSR-17 response factory found. Install a package from this list: https://packagist.org/providers/psr/http-factory-implementation

Could not find resource using any discovery strategy. Find more information at http://docs.php-http.org/en/latest/discovery.html#common-errors - Puli Factory is not available - No valid candidate found using strategy "Http\Discovery\Strategy\CommonClassesStrategy". We tested the following candidates: . - No valid candidate found using strategy "Http\Discovery\Strategy\CommonPsr17ClassesStrategy". We tested the following candidates: Nyholm\Psr7\Factory\Psr17Factory, Zend\Diactoros\ResponseFactory, Http\Factory\Diactoros\ResponseFactory, Http\Factory\Guzzle\ResponseFactory, Http\Factory\Slim\ResponseFactory.

So when I revert this:

    public static function safeClassExists($class)
    {
        try {
            return class_exists($class) || interface_exists($class);
        } catch (\Exception $e) {
            return false;
        }

Back to the old behavior:

    public static function safeClassExists($class)
    {
        try {
            return class_exists($class);
        } catch (\Exception $e) {
            return false;
        }

Now the error is gone.

The debug trace points to https://github.com/FriendsOfSymfony/FOSHttpCache/blob/master/src/ProxyClient/HttpDispatcher.php#L99

Any idea what this could be?

Currently code is duplicated in Message and Stream factories. Thanks to @mekras we now have Stream factories which we can use to create streams.

Few solutions in my mind:

1. Accept a StreamFactory in the MessageFactory constructor (downside: increases complexity, also, I don't want the Guzzle message factory to use the diactoros one)
2. Instantiate the corresponding StreamFactory in the Message factory. (downside: hard coupling)
3. Mixture of the two: accept setter injection but fallback to a default implementation.

Currently we have clients like this:

class Client implements HttpClient
{
    public function __construct(MessageFactory $mf = null)
    {
       // Use discovery if MF is not passed
    }
}

I think we should rather force the user to pass a message factory and use the discovery manually OR use a static constructor, like Client::zeroConfig to setup the client.

The big advantage would be forcing DI and removing discovery dependency from client implementations.

Are there any cases where we want to extend them?

They are pretty simple, so I don't think reimplementing them is a problem.

Actual Behavior

A DiscoveryFailedException is thrown.

Expected Behavior

An instance of the mock client.

Steps to Reproduce

Using the Psr18ClientDiscovery will result in a DiscoveryFailedException (MockClientStrategy is prepended) since the current MockClientStrategy have no candidate for the PSR ClientInterface.

Possible Solutions

Will open a PR soon.

We need static access, but the discovery layer itself should not be static.

Hello can you check the following build: https://travis-ci.org/florianv/exchanger/jobs/474973917

The reason is that on this line: https://github.com/php-http/discovery/blob/master/src/Exception/NoCandidateFoundException.php#L27 variable $classes contains:

array (
  0 => 'Http\\Adapter\\Guzzle6\\Client',
  1 => 'Http\\Adapter\\Guzzle5\\Client',
  2 => 'Http\\Client\\Curl\\Client',
  3 => 'Http\\Client\\Socket\\Client',
  4 => 'Http\\Adapter\\Buzz\\Client',
  5 => 'Http\\Adapter\\React\\Client',
  6 => 'Http\\Adapter\\Cake\\Client',
  7 => 'Http\\Adapter\\Zend\\Client',
  8 => 'Http\\Adapter\\Artax\\Client',
  9 => 
  array (
    0 => 'Http\\Discovery\\Strategy\\CommonClassesStrategy',
    1 => 'buzzInstantiate',
  ),
)

You can see the double array above.

I am using mailgun's php lib that depends on client discovery.

The following code is the first strategy tried and it'll always throw an exception since there is no stable puli implementation available, and from the looks of it, there never will be:

I like to keep 'break on exceptions' on in my IDE but this exception gets thrown in the normal course of its business, which is problematic. I don't have any other libs that use this method of flow control (and if you're interested, I can make a good argument as to why it is a bad idea ;)).

If you'd be open to a PR that either a) makes puli the second strategy instead of the first so no exeption gets thrown, b) removes the puli strategy, and/or c) changes the logic so an exception is only thrown if a strategy can't be found, I'd be glad to cook it up and submit it.

Once puli/issues#165 is done

Hi,

I installed mailgun/mailgun-php https://github.com/mailgun/mailgun-php using it's recommended line below

php composer.phar require mailgun/mailgun-php php-http/curl-client guzzlehttp/psr7

This all works fine for me. In the logs though I see loads of notice messages around Nyholm not loading which is correct cause I didn't require it when running the above command. CommonClassesStrategy.php is including these as part of php-http package so it's trying to load them.

What is the correct approach to removing these dependencies without commenting out the includes manually?

The mailgun-php team posted the response below:

If you posted this issue on php-http/discovery you would gotten a much quicker reply. The php-http/discovery package is doing a few class_exists() calls. I assume that is why you get this messages.

Can you recommend a way for me to stop this logging from happening cleanly?

Thanks,

Shaun.

Last release was in August. We have a few minor commits in master that is not released yet. What do you think of releasing 1.4.0 this year?

Actual Behavior

I'm using the thephpleague/omnipay package and since the release of the version 1.7.1, HttpClientDiscovery is not able to find the http client I'm using (symfony/http-client) any more.

+"message": "No HTTPlug clients found. Make sure to install a package providing "php-http/client-implementation". Example: "php-http/guzzle6-adapter"."
+"exception": "Http\Discovery\NotFoundException"

Expected Behavior

I would expect discovery to find symfony http client.

And probably UriFactory implementations for Guzzle and Diactoros?

Discovery classes should accept a Puli discovery

I just update my vendor and the puli build command becomes broken. I have try to remove my local puli.json and ./puli directory but still got the same error.

Here the stacktrace of the puli build command:

./bin/puli build -vv



  [InvalidArgumentException]                  
  The flags must be an integer. Got: boolean  



Exception trace:
  ()
    vendor/webmozart/assert/src/Assert.php:149
  Webmozart\Assert\Assert::integer()
    vendor/webmozart/key-value-store/src/JsonFileStore.php:119
  Webmozart\KeyValueStore\JsonFileStore->__construct()
    .puli/GeneratedPuliFactory.php:41
  Puli\GeneratedPuliFactory->createRepository()
    vendor/puli/manager/src/Api/Puli.php:508
  Puli\Manager\Api\Puli->getRepository()
    vendor/puli/manager/src/Api/Puli.php:653
  Puli\Manager\Api\Puli->getRepositoryManager()
    vendor/puli/cli/src/PuliApplicationConfig.php:208
  Puli\Cli\PuliApplicationConfig->Puli\Cli\{closure}()
    n/a:n/a
  call_user_func()
    vendor/webmozart/console/src/Api/Config/Config.php:285
  Webmozart\Console\Api\Config\Config->getHandler()
    vendor/webmozart/console/src/Api/Command/Command.php:499
  Webmozart\Console\Api\Command\Command->doHandle()
    vendor/webmozart/console/src/Api/Command/Command.php:388
  Webmozart\Console\Api\Command\Command->handle()
    vendor/webmozart/console/src/ConsoleApplication.php:266
  Webmozart\Console\ConsoleApplication->run()
    vendor/puli/cli/bin/puli:23

Hi,

If I'm right, this lib is not compatible with PHP 5.4 just because of "::class" used in tests. Are you against a PR which will replace "::class" by the fully qualified class name ?

Best regards.

The introduction of Puli requires people to have Puli’s CLI installed for discovery to work (when running composer install/update). Is that correct, @sagikazarmark?

We added a few more adapters in the common strategy. There are no planned features at this point. I suggest to release 1.3 next week.

Actual Behavior

The discovery doesn't discover the symfony http client, especially its psr-18 bridge. Would be great to support that IMO.

Expected Behavior

Being able to discover the PSR-18 adapter of the brand new Symfony HttpClient component.

I'll try a PR once the component is merged and released (or maybe before ?)

Please remove dependency on puli. We do not use it, nor symfony stuff. The dependency is too much for our project. I like the discovery for the adapters, but...

Reverting php-http/discovery back to 0.5 saves a lot of deps!

- Removing padraic/phar-updater (dev-master)
- Removing symfony/finder (2.8.x-dev)
- Removing padraic/humbug_get_contents (dev-master)
- Removing webmozart/console (dev-master)
- Removing symfony/console (2.8.x-dev)
- Removing symfony/polyfill-mbstring (dev-master)
- Removing symfony/process (2.8.x-dev)
- Removing psr/log (dev-master)
- Removing ramsey/uuid (2.8.x-dev)
- Removing symfony/event-dispatcher (2.8.x-dev)
- Removing symfony/filesystem (2.8.x-dev)
- Removing webmozart/expression (dev-master)
- Removing webmozart/key-value-store (dev-master)
- Removing webmozart/json (dev-master)
- Removing seld/jsonlint (1.4.0)
- Removing justinrainbow/json-schema (1.5.0)
- Removing webmozart/glob (dev-master)
- Removing webmozart/path-util (dev-master)
- Removing webmozart/assert (dev-master)

It’d be nice to only have to rely on tagged versions in https://github.com/FriendsOfSymfony/FOSHttpCache/pull/173/files.

We had many complaints about using puli in the discovery layer. Although I love it and for me it made it easier to discover clients, not everyone feels the same.

One of the most common complaints is about dependencies: php-http/httplug#101 (comment)

I think Puli improved a lot on this front in the near past.

All in all: we should investigate the case and see if we can make Puli optional.

AFAIK @Nyholm came up with an idea (maybe something that Payum implemented?) to maintain a list of known resources in the discovery and fallback to Puli (if installed).

Althought I don't like the idea of having multiple discovery ways, I thought I would ask for feedback to see what other think about it.

Discovery was always something which I treated as a stepchildren. Personally, I don't like to use it. Makes things easier, but provides us less control.

Actual Behavior

I'm getting exception:

Uncaught PHP Exception Http\Discovery\NotFoundException: "No message factories found. To use Guzzle, Diactoros or Slim Framework factories install php-http/message and the chosen message implementation." at /myproject/vendor/php-http/discovery/src/MessageFactoryDiscovery.php line 27 {"exception":"[object] (Http\Discovery\NotFoundException(code: 0): No message factories found. To use Guzzle, Diactoros or Slim Framework factories install php-http/message and the chosen message implementation. at /myproject/vendor/php-http/discovery/src/MessageFactoryDiscovery.php:27, Http\Discovery\Exception\DiscoveryFailedException(code: 0): Could not find resource using any discovery strategy. Find more information at http://docs.php-http.org/en/latest/discovery.html#common-errors\n - Puli Factory is not available\n\n at /myproject/vendor/php-http/discovery/src/Exception/DiscoveryFailedException.php:41

Expected Behavior

No exception

Steps to Reproduce

Sadly, I don't know. Local (dev) environment is working. Remote (prod) environment throws exception.
My installed dependencies (only relevant ones):

guzzlehttp/psr7                    1.4.2              PSR-7 message impleme...
kriswallsmith/buzz                 v0.15.2            Lightweight HTTP client
php-http/buzz-adapter              1.0.0              Buzz HTTP Adapter
php-http/curl-client               v1.7.1             cURL client for PHP-HTTP
php-http/discovery                 1.4.0              Finds installed HTTPl...
php-http/httplug                   v1.1.0             HTTPlug, the HTTP cli...
php-http/message                   1.7.0              HTTP Message related ...
php-http/message-factory           v1.0.2             Factory interfaces fo...
php-http/promise                   v1.0.0             Promise used for asyn...
psr/cache                          1.0.1              Common interface for ...
psr/container                      1.0.0              Common Container Inte...
psr/http-message                   1.0.1              Common interface for ...
psr/log                            1.0.2              Common interface for ...
psr/simple-cache                   1.0.1              Common interfaces for...

I started this issue from the discussion here: php-http/HttplugBundle#81

Our BC promise in this library is the following functions:

HttpAsyncClientDiscovery::find();
HttpClientDiscovery::find();
MessageFactoryDiscovery::find();
StreamFactoryDiscovery::find();
UriFactoryDiscovery::find();

ClassDiscovery::setStrategies();
ClassDiscovery::clearCache();

// And the
DiscoveryStrategy interface

// And our exceptions and when they are thrown

This API has nothing to do with the discovery methods (strategies) itself. The strategy classes should not be a part of our API promise. Which is a great thing.

If we change the namespace of our clients we just add another "NewNamespacesStrategy" together with our existing CommonClassesStrategy. Same with if Puli changes their API when they release 1.0. We just add a "Puli1Strategy".

So if we leave the strategies outside our BC promise, are we ready for a stable release? At least, can we mature in to this API and tag 1.0 after the summer?

we should enable travis for this repository and fix the phpspec tests. HttpClientDiscoverySpec still uses Http\Adapter\HttpAdapter which can't be right. there is not even a dependency on php-http/httplug. we might also want some functional tests that instantiate an actual client.

in #40 we locked to specific versions to avoid unstable versions. we need to revert that again.

see also #41, where we might clean up what we depend on.

My monitoring system often shows the following errors:

Http\Discovery\Exception\PuliUnavailableException:Puli Factory is not available in vendor/php-http/discovery/src/Strategy/PuliBetaStrategy.php on line 40

I looked at where this error came from and found that it was because PULI_FACTORY_CLASS was not defined. Where is this constant defined?

After upgrading to Symfony 4.4, I got the following error:

bin/console

Stack trace:

[Http\Discovery\Exception\ClassInstantiationFailedException]  
  Unexpected exception when instantiating class

  at vendor/php-http/discovery/src/ClassDiscovery.php:210
 Http\Discovery\ClassDiscovery::instantiateClass() at vendor/php-http/discovery/src/HttpClientDiscovery.php:34
 Http\Discovery\HttpClientDiscovery::find() at vendor/friendsofapi/localise.biz/src/HttpClientConfigurator.php:59
 FAPI\Localise\HttpClientConfigurator->__construct() at var/cache/dev/ContainerBZs79FG/getPhpTranslation_Adapter_LocoService.php:17
 require() at var/cache/dev/ContainerBZs79FG/srcApp_KernelDevDebugContainer.php:742
 ContainerBZs79FG\srcApp_KernelDevDebugContainer->load() at var/cache/dev/ContainerBZs79FG/getPhpTranslation_Storage_WdaService.php:16
 require() at var/cache/dev/ContainerBZs79FG/srcApp_KernelDevDebugContainer.php:742
 ContainerBZs79FG\srcApp_KernelDevDebugContainer->load() at var/cache/dev/ContainerBZs79FG/getPhpTranslation_StorageManagerService.php:13
 require() at var/cache/dev/ContainerBZs79FG/srcApp_KernelDevDebugContainer.php:742
 ContainerBZs79FG\srcApp_KernelDevDebugContainer->load() at var/cache/dev/ContainerBZs79FG/getPhpTranslator_Console_DeleteObsoleteService.php:15
 require() at var/cache/dev/ContainerBZs79FG/srcApp_KernelDevDebugContainer.php:742
 ContainerBZs79FG\srcApp_KernelDevDebugContainer->load() at vendor/symfony/dependency-injection/Container.php:444
 Symfony\Component\DependencyInjection\Container->getService() at vendor/symfony/dependency-injection/Argument/ServiceLocator.php:40
 Symfony\Component\DependencyInjection\Argument\ServiceLocator->get() at vendor/symfony/console/CommandLoader/ContainerCommandLoader.php:45
 Symfony\Component\Console\CommandLoader\ContainerCommandLoader->get() at vendor/symfony/console/Application.php:542
 Symfony\Component\Console\Application->has() at vendor/symfony/console/Application.php:743
 Symfony\Component\Console\Application->all() at vendor/symfony/framework-bundle/Console/Application.php:143
 Symfony\Bundle\FrameworkBundle\Console\Application->all() at vendor/symfony/console/Descriptor/ApplicationDescription.php:91
 Symfony\Component\Console\Descriptor\ApplicationDescription->inspectApplication() at vendor/symfony/console/Descriptor/ApplicationDescription.php:68
 Symfony\Component\Console\Descriptor\ApplicationDescription->getCommands() at vendor/symfony/console/Descriptor/TextDescriptor.php:202
 Symfony\Component\Console\Descriptor\TextDescriptor->describeApplication() at vendor/symfony/console/Descriptor/Descriptor.php:55
 Symfony\Component\Console\Descriptor\Descriptor->describe() at vendor/symfony/console/Helper/DescriptorHelper.php:67
 Symfony\Component\Console\Helper\DescriptorHelper->describe() at vendor/symfony/console/Command/ListCommand.php:75
 Symfony\Component\Console\Command\ListCommand->execute() at vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at vendor/symfony/console/Application.php:1029
 Symfony\Component\Console\Application->doRunCommand() at vendor/symfony/framework-bundle/Console/Application.php:100
 Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at vendor/symfony/console/Application.php:272
 Symfony\Component\Console\Application->doRun() at vendor/symfony/framework-bundle/Console/Application.php:83
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at vendor/symfony/console/Application.php:148
 Symfony\Component\Console\Application->run() at bin/console:36

Related packages I have installed:

php-http/guzzle6-adapter
php-translation/symfony-bundle
php-translation/loco-adapter

I fixed it by installing http-interop/http-factory-guzzle but I wonder what has changed in Symfony 4.4 that broke the http discovery?

I have been looking at puli for the last few weeks. I think @joelwurtz also spent some time with it, at least during PHP Forum with @webmozart.

I think it is quite awesome and we could easily use it not just in the discovery package, but in the whole project. Since we have nice contracts, we already have out binding types: HttpClient, HttpAsyncClient, *Factory. In each of our packages we can provide a puli.json with the actual bindings (like Guzzle6HttpAdapter is bind to HttpClient and HttpAsyncClient)

Downside of this solution is that every resource must be registered in the repository (?) and conditional auto-discovery (and caching) during runtime won't work. However, this is not necessarily a downside, but probably makes flexibility a bit harder.

While this could make our static discoveries obsolete, I would still keep them. Although Puli does not recommend it to use it in global context or instantiate it more than once, I think we should use them inside our discovery layer. The workflow would be the following:

If someone wants to resolve something from the discovery, and it is the first call to any discoveries, we instantiate the Puli factory and store it in the ClassDiscovery object. After that, inside the specific discovery (like HttpClientDiscovery) we loop through our internal list of clients and append them to Puli ONCE. We set an initialized bit or something. This replaces our internal cache mechanism. After that, we resolve the first match of the specific binding and return it.

Possible pitfalls:

• Performance: Puli recommends NOT to this global context thing for performance (and other) reasons. However our discovery thing's aim is zero config, which itself is not recommended. Configuration, DI should be used, but if you need it as is, you can use it. Not sure if we need to care about this apart from placing a big fat warning somewhere.
• Priority: not sure about Puli's priority handling. FIFO? LIFO? Does it really matter? IMO when we use a discovery, we just want something fast, should we really care about priorities? Currently it is possible to add resources to discoveries and they are returned FIFO.
• Puli required: with this we would add puli as a dependency. Not sure if it is really a downside, as puli is quite awesome. Putting a puli.json file in all of the related repos should really not be a problem.

Reference:
https://speakerdeck.com/webmozart/puli-phps-next-package-revolution?slide=102

Just a quick question: In Http\Discovery\Strategy\CommonClassesStrategy you use classes i.e. Nyholm\Psr7\Request and this dependency is not defined in the composer.json. How does it work? This package composer.json states:

"require": {
        "php": "^5.5 || ^7.0"
    }

The Nyholm composer.json (https://github.com/Nyholm/psr7/blob/master/composer.json) states:

"require": {
        "php": "^7.1",

How can I use this package without conflicts and how is it supposed to be used when the dependencies are not explicitly declared? Thanks a lot guys.

Actual Behavior

It doesn't support PSR-17 factories

Expected Behavior

It should support PSR-17 factories (such as @Nyholm's psr-7 package, as the httpplug is already supported)

Possible Solutions

Allow to discover the psr-17 interfaces and the implementations that supports those (or at least the most popular ones, such as @Nyholm's psr-17 and zend diactoros - didn't look at the others)

First, let me say that I'm really glad you folks are trying to make HTTP client discovery easy. It makes building tools much simpler.

That being said, after numerous attempts, I cannot seem to use the latest version of discovery. Hopefully I'm just missing something.

Here is the output from a completely empty project:

Step 1: composer require php-http/discovery

mike at crumm in ~/Code/mcrumm/php-http-discovery-test
$ composer require php-http/discovery
Using version ^0.6.3 for php-http/discovery
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing webmozart/expression (1.0.0)
    Loading from cache

  - Installing symfony/event-dispatcher (v2.8.1)
    Loading from cache

  - Installing symfony/process (v2.8.1)
    Loading from cache

  - Installing symfony/polyfill-mbstring (v1.0.1)
    Loading from cache

  - Installing symfony/console (v2.8.1)
    Loading from cache

  - Installing webmozart/assert (1.0.2)
    Loading from cache

  - Installing webmozart/console (1.0.0-beta4)
    Loading from cache

  - Installing justinrainbow/json-schema (v1.6.0)
    Loading from cache

  - Installing seld/jsonlint (1.4.0)
    Loading from cache

  - Installing webmozart/json (1.2.0)
    Loading from cache

  - Installing webmozart/path-util (2.3.0)
    Loading from cache

  - Installing ramsey/uuid (2.8.4)
    Loading from cache

  - Installing psr/log (1.0.0)
    Loading from cache

  - Installing webmozart/glob (3.3.1)
    Loading from cache

  - Installing puli/repository (1.0.0-beta8)
    Loading from cache

  - Installing symfony/filesystem (v2.8.1)
    Loading from cache

  - Installing puli/discovery (1.0.0-beta8)
    Loading from cache

  - Installing puli/url-generator (1.0.0-beta3)
    Loading from cache

  - Installing padraic/humbug_get_contents (1.0.4)
    Loading from cache

  - Installing padraic/phar-updater (1.0.3)
    Loading from cache

  - Installing webmozart/key-value-store (1.0.0-beta6)
    Loading from cache

  - Installing puli/manager (1.0.0-beta9)
    Loading from cache

  - Installing puli/cli (1.0.0-beta9)
    Loading from cache

  - Installing puli/composer-plugin (1.0.0-beta8)
    Loading from cache

  - Installing php-http/discovery (v0.6.3)
    Loading from cache

symfony/event-dispatcher suggests installing symfony/dependency-injection ()
symfony/event-dispatcher suggests installing symfony/http-kernel ()
ramsey/uuid suggests installing moontoast/math (Support for converting UUID to 128-bit integer (in string form).)
ramsey/uuid suggests installing doctrine/dbal (Allow the use of a UUID as doctrine field type.)
webmozart/key-value-store suggests installing predis/predis (To enable the PredisStore)
webmozart/key-value-store suggests installing basho/riak (To enable the RiakStore)
webmozart/key-value-store suggests installing doctrine/cache (To enable the CachedStore)
webmozart/key-value-store suggests installing doctrine/dbal (To enable the DbalStore)
php-http/discovery suggests installing php-http/message (Allow to use Guzzle or Diactoros factories)
Writing lock file
Generating autoload files
Generating PULI_FACTORY_CLASS constant
Registering Puli\GeneratedPuliFactory with the class-map autoloader
Setting "bootstrap-file" to "vendor/autoload.php"
Looking for updated Puli packages
Installing webmozart/expression (vendor/webmozart/expression) in prod
Installing symfony/event-dispatcher (vendor/symfony/event-dispatcher) in prod
Installing symfony/process (vendor/symfony/process) in prod
Installing symfony/polyfill-mbstring (vendor/symfony/polyfill-mbstring) in prod
Installing symfony/console (vendor/symfony/console) in prod
Installing webmozart/assert (vendor/webmozart/assert) in prod
Installing webmozart/console (vendor/webmozart/console) in prod
Installing justinrainbow/json-schema (vendor/justinrainbow/json-schema) in prod
Installing seld/jsonlint (vendor/seld/jsonlint) in prod
Installing webmozart/json (vendor/webmozart/json) in prod
Installing webmozart/path-util (vendor/webmozart/path-util) in prod
Installing ramsey/uuid (vendor/ramsey/uuid) in prod
Installing psr/log (vendor/psr/log) in prod
Installing webmozart/glob (vendor/webmozart/glob) in prod
Installing puli/repository (vendor/puli/repository) in prod
Installing symfony/filesystem (vendor/symfony/filesystem) in prod
Installing puli/discovery (vendor/puli/discovery) in prod
Installing puli/url-generator (vendor/puli/url-generator) in prod
Installing padraic/humbug_get_contents (vendor/padraic/humbug_get_contents) in prod
Installing padraic/phar-updater (vendor/padraic/phar-updater) in prod
Installing webmozart/key-value-store (vendor/webmozart/key-value-store) in prod
Installing puli/manager (vendor/puli/manager) in prod
Installing puli/cli (vendor/puli/cli) in prod
Installing puli/composer-plugin (vendor/puli/composer-plugin) in prod
Installing php-http/discovery (vendor/php-http/discovery) in prod
Running "puli build"

Step 2: composer require --dev php-http/guzzle6-adapter

mike at crumm in ~/Code/mcrumm/php-http-discovery-test
$ composer require --dev php-http/guzzle6-adapter
Using version ^0.3.1 for php-http/guzzle6-adapter
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing psr/http-message (1.0)
    Loading from cache

  - Installing guzzlehttp/psr7 (1.2.1)
    Loading from cache

  - Installing guzzlehttp/promises (1.0.3)
    Loading from cache

  - Installing guzzlehttp/guzzle (6.1.1)
    Loading from cache

  - Installing php-http/promise (v0.1.1)
    Loading from cache

  - Installing php-http/message-factory (v1.0.2)
    Loading from cache

  - Installing php-http/httplug (v1.0.0-beta)
    Loading from cache

  - Installing php-http/client-common (v0.1.1)
    Loading from cache

  - Installing php-http/guzzle6-adapter (v0.3.1)
    Loading from cache

Writing lock file
Generating autoload files
Generating PULI_FACTORY_CLASS constant
Registering Puli\GeneratedPuliFactory with the class-map autoloader
Looking for updated Puli packages
Installing psr/http-message (vendor/psr/http-message) in dev
Warning: Could not install package "psr/http-message" (at ./vendor/psr/http-message): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/puli.json is invalid:
  packages.psr/http-message: The property env is not defined and the
  definition does not allow additional properties
Installing guzzlehttp/psr7 (vendor/guzzlehttp/psr7) in dev
Warning: Could not install package "guzzlehttp/psr7" (at ./vendor/guzzlehttp/psr7): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/puli.json is invalid:
  packages.guzzlehttp/psr7: The property env is not defined and the
  definition does not allow additional properties
Installing guzzlehttp/promises (vendor/guzzlehttp/promises) in dev
Warning: Could not install package "guzzlehttp/promises" (at ./vendor/guzzlehttp/promises): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/puli.json is invalid:
  packages.guzzlehttp/promises: The property env is not defined and the
  definition does not allow additional properties
Installing guzzlehttp/guzzle (vendor/guzzlehttp/guzzle) in dev
Warning: Could not install package "guzzlehttp/guzzle" (at ./vendor/guzzlehttp/guzzle): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/puli.json is invalid:
  packages.guzzlehttp/guzzle: The property env is not defined and the
  definition does not allow additional properties
Installing php-http/promise (vendor/php-http/promise) in dev
Warning: Could not install package "php-http/promise" (at ./vendor/php-http/promise): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/puli.json is invalid:
  packages.php-http/promise: The property env is not defined and the
  definition does not allow additional properties
Installing php-http/message-factory (vendor/php-http/message-factory) in dev
Warning: Could not install package "php-http/message-factory" (at ./vendor/php-http/message-factory): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/puli.json is invalid:
  packages.php-http/message-factory: The property env is not defined and the
  definition does not allow additional properties
Installing php-http/httplug (vendor/php-http/httplug) in dev
Warning: Could not install package "php-http/httplug" (at ./vendor/php-http/httplug): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/puli.json is invalid:
  packages.php-http/httplug: The property env is not defined and the
  definition does not allow additional properties
Installing php-http/client-common (vendor/php-http/client-common) in dev
Warning: Could not install package "php-http/client-common" (at ./vendor/php-http/client-common): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/puli.json is invalid:
  packages.php-http/client-common: The property env is not defined and the
  definition does not allow additional properties
Installing php-http/guzzle6-adapter (vendor/php-http/guzzle6-adapter) in dev
Warning: Could not install package "php-http/guzzle6-adapter" (at ./vendor/php-http/guzzle6-adapter): InvalidConfigException: The configuration in
  /Users/mike/Code/mcrumm/php-http-discovery-test/vendor/php-http/guzzle6-adapter/puli.json
  is invalid:
  bindings.04b5a002-71a8-473d-a8df-75671551b84a.query: Is missing and it is
  required
  bindings.9c856476-7f6b-43df-a740-15420a5f839c.query: Is missing and it is
  required
Running "puli build"

At this point I'm confused by the install and configuration errors, but composer says it installed my packages.

Step 3: Show the packages

mike at crumm in ~/Code/mcrumm/php-http-discovery-test
$ composer show -i
guzzlehttp/guzzle           6.1.1       Guzzle is a PHP HTTP client library
guzzlehttp/promises         1.0.3       Guzzle promises library
guzzlehttp/psr7             1.2.1       PSR-7 message implementation
justinrainbow/json-schema   v1.6.0      A library to validate a json schema.
padraic/humbug_get_contents 1.0.4       Secure wrapper for accessing HTTPS resources with file_get_contents for PHP 5.3+
padraic/phar-updater        1.0.3       A thing to make PHAR self-updating easy and secure.
php-http/client-common      v0.1.1      Common HTTP Client implementations and tools for HTTPlug
php-http/discovery          v0.6.3      Finds installed HTTPlug implementations and PSR-7 message factories
php-http/guzzle6-adapter    v0.3.1      Guzzle 6 HTTP Adapter
php-http/httplug            v1.0.0-beta HTTPlug, the HTTP client abstraction for PHP
php-http/message-factory    v1.0.2      Factory interfaces for PSR-7 HTTP Message
php-http/promise            v0.1.1      Promise used for asynchronous HTTP requests
psr/http-message            1.0         Common interface for HTTP messages
psr/log                     1.0.0       Common interface for logging libraries
puli/cli                    1.0.0-beta9 A Command Line Interface (CLI) for managing Puli projects.
puli/composer-plugin        1.0.0-beta8 Integrates Composer into the Puli package manager.
puli/discovery              1.0.0-beta8 Publishes and discovers artifacts across Puli packages.
puli/manager                1.0.0-beta9 Generates Puli repositories from configured packages.
puli/repository             1.0.0-beta8 A filesystem-like repository for storing arbitrary resources.
puli/url-generator          1.0.0-beta3 Generates URLs for public Puli resources.
ramsey/uuid                 2.8.4       A PHP 5.3+ library for generating RFC 4122 version 1, 3, 4, and 5 universally unique identifiers (UUID).
seld/jsonlint               1.4.0       JSON Linter
symfony/console             v2.8.1      Symfony Console Component
symfony/event-dispatcher    v2.8.1      Symfony EventDispatcher Component
symfony/filesystem          v2.8.1      Symfony Filesystem Component
symfony/polyfill-mbstring   v1.0.1      Symfony polyfill for the Mbstring extension
symfony/process             v2.8.1      Symfony Process Component
webmozart/assert            1.0.2       Assertions to validate method input/output with nice error messages.
webmozart/console           1.0.0-beta4 A usable, beautiful and easily testable console toolkit written in PHP.
webmozart/expression        1.0.0       Formulate expressions and search criteria using PHP objects.
webmozart/glob              3.3.1       A PHP implementation of Ant's glob.
webmozart/json              1.2.0       A robust JSON decoder/encoder with support for schema validation.
webmozart/key-value-store   1.0.0-beta6 A key-value store API with implementations for different backends.
webmozart/path-util         2.3.0       A robust cross-platform utility for normalizing, comparing and modifying file paths.

So I assume that discovery will discover the Guzzle6 adapter when I ask for it. Here's my test script:

Step 4: Show the test script to the good folks at php-http

mike at crumm in ~/Code/mcrumm/php-http-discovery-test
$ cat discover.php

<?php

require __DIR__ . '/vendor/autoload.php';

$dis = Http\Discovery\HttpClientDiscovery::find();

var_dump(get_class($dis));

But, no such luck.

Step 5: See error, cry myself to sleep 😭

mike at crumm in ~/Code/mcrumm/php-http-discovery-test
$ php discover.php

PHP Fatal error:  Uncaught Http\Discovery\NotFoundException: Resource of type "Http\Client\HttpClient" not found in /Users/mike/Code/mcrumm/php-http-discovery-test/vendor/php-http/discovery/src/ClassDiscovery.php:114
Stack trace:
#0 /Users/mike/Code/mcrumm/php-http-discovery-test/vendor/php-http/discovery/src/HttpClientDiscovery.php(21): Http\Discovery\ClassDiscovery::findOneByType('Http\\Client\\Htt...')
#1 /Users/mike/Code/mcrumm/php-http-discovery-test/discover.php(7): Http\Discovery\HttpClientDiscovery::find()
#2 {main}
  thrown in /Users/mike/Code/mcrumm/php-http-discovery-test/vendor/php-http/discovery/src/ClassDiscovery.php on line 114

Fatal error: Uncaught Http\Discovery\NotFoundException: Resource of type "Http\Client\HttpClient" not found in /Users/mike/Code/mcrumm/php-http-discovery-test/vendor/php-http/discovery/src/ClassDiscovery.php on line 114

Http\Discovery\NotFoundException: Resource of type "Http\Client\HttpClient" not found in /Users/mike/Code/mcrumm/php-http-discovery-test/vendor/php-http/discovery/src/ClassDiscovery.php on line 114

Call Stack:
    0.0002     365136   1. {main}() /Users/mike/Code/mcrumm/php-http-discovery-test/discover.php:0
    0.0034     729880   2. Http\Discovery\HttpClientDiscovery::find() /Users/mike/Code/mcrumm/php-http-discovery-test/discover.php:7
    0.0035     729880   3. Http\Discovery\ClassDiscovery::findOneByType() /Users/mike/Code/mcrumm/php-http-discovery-test/vendor/php-http/discovery/src/HttpClientDiscovery.php:21

Help?

This has been discussed a few times now, but keeps coming back, so I open a new issue for this.

Generally, adding it as a dependency in a package is not recommended by @webmozart

It is also under discussion to make discovery optional everywhere, like in Guzzle 5:

https://github.com/php-http/guzzle5-adapter/blob/master/src/Client.php#L39

In this case, we would end up with two separate dependencies:

• Discovery
• Puli composer plugin

However, we could make discovery itself required dependency and only require to manually install the puli composer plugin.

I think for consistency, we should rename HttpAdapterDiscovery to HttpClientDiscovery.

Hello,

I'm using the Happyr/LinkedIn-API-client package, which has recently been updated to use PSR-7.

Since the update I'm getting the following error:

[RuntimeException]             
Puli Factory is not available

This happens in the ClassDiscovery class on getPuliFactory method.

When going to https://github.com/puli/factory, I see it's not maintained anymore.

Anything I missed ?

In some cases it doesn't matter if the installed client is sync or async (for example when known to be used in PluginClient). For that we could have a discovery which finds a sync or async client.

Hello :)

I am trying to use AcceptOn (https://github.com/accepton/accepton-php) which is using php-http.

I use:

• Windows 10 x64
• Xampp with php 7
• Composer

After some hassle I can instantiate the Client from AcceptOn. But when using the functionality I get Fatal error: Uncaught Error: Class 'Puli\GeneratedPuliFactory' not found in D:\Development\Repository\order\vendor\php-http\discovery\src\ClassDiscovery.php on line 37. The GeneratedPuliFactory.php is inside the .puli directory which is in the project root (order). The puli.phar is also located in the root directory and can be called via php puli.phar.

I also checked http://docs.php-http.org/en/latest/discovery.html#common-errors and run composer require puli/composer-plugin. Sadly the problem still exists.

Any Idea how I can solve this?
Thanks!

Actual Behavior

Due to the missing dependency, the sourcecode of nyholm/psr7 is never retrieved from packagist.org, resulting in the following bug:

[2018-03-07 15:33:57] main.ERROR: Source class "\Nyholm\Psr7\Factory\Stream" for "Nyholm\Psr7\Factory\StreamFactory" generation does not exist. [] []

Expected Behavior

No errors...

Steps to Reproduce

1. git clone
2. composer install
3. run it?

Possible Solutions

specify nyholm/psr7 in the require section of composer.json

Currently discovery classes are used in case a resource (Client, MessageFactory, etc) is not passed. Used as a fallback if you like. However these fallbacks are usually resolved in a constructor which makes them immediately instantiated, which does not make much sense, if you can also set the resource using a setter.

To mitigate this problem, I propose to implement Auto/Lazy discover, which would work like the following: instead of using the find method of discoveries, a new Autodiscovery object is instantiated (specific to the resource type).

When you actually want to use this resource the first time, the autodiscovery gets initialized and invokes the underlying find method.

PS: I realized after writting the description that I actually described Proxies. So lets call them Proxies instead.

At the moment we got a clear and straight forward message when Puli Factory is not found or Puli Factory class does not exist. (Source) I believe many users is going to face that message. I would suggest to do something that helps the user to know what next step to take.

Suggestions:

• Include a link to http://docs.php-http.org/ that clearly explains what actions to take.
• Make the exception more unique and easier to Google. Maybe include "Httplug"?

Unfortunately guzzle/psr7#50 hasn't been accepted which made me think about the current state of factories and discovery.

Currently we have all our Factory implementations in the discovery repo, which makes the actual implementations nearly unusable in cases where the discovery layer is not needed.

IIRC @mekras suggested a while ago to separate the factories from the discovery layer. Although we refused to do (I don't remember the reasons, probably to many packages and dependencies?) we should reconsider this. I see three possible ways:

1. Leave it as is.

2. Separate factories to implementation specific packages and

   A. require the implementation itself as well
   B. only suggest the implementation

In case of "A" we cannot really use the factories automatically anymore in the discovery layer, but we have to install them manually, based on the chosen implementation.

In case of "B" we can require all the factory packages in the discovery layer, so we could use it as usual. Although in this case we also install lots of extra dependencies.

When we do not find a factory we throw an exception like this:

"No factories found. Install php-http/message to use Guzzle or Diactoros factories."

This is not correct. You could have php-http/message installed and still get this error. We should explain better that you need php-http/message and an implementation of PSR-7.

Same with the HttpAsyncClientDiscovery and HttpClientDiscovery, atm we get an exception saying "Not found". This could also be improved.

As discussed in #4

Reason against it: it allows to identify a class resource and allows to override it when registering one.

/cc @ddeboer

Should we have a plan?

As this package has been updated with the support of the new Symfony Http Client and priorities being reset for the Buzz client, shouldn't we release a new version ? Even though the changelog may be a bit skinny.

Possible Solutions

Release 1.7.0 ? :}

It seems #149 is still not fixed. The fix that was proposed in #150 was reverted in #151

No PSR-17 response factory found. Install a package from this list: https://packagist.org/providers/psr/http-factory-implementation

Could not find resource using any discovery strategy. Find more information at http://docs.php-http.org/en/latest/discovery.html#common-errors

• Puli Factory is not available
• No valid candidate found using strategy "Http\Discovery\Strategy\CommonClassesStrategy". We tested the following candidates: .
• No valid candidate found using strategy "Http\Discovery\Strategy\CommonPsr17ClassesStrategy". We tested the following candidates: Nyholm\Psr7\Factory\Psr17Factory, Zend\Diactoros\ResponseFactory, Http\Factory\Diactoros\ResponseFa
  ctory, Http\Factory\Guzzle\ResponseFactory, Http\Factory\Slim\ResponseFactory.

Any reason that diactoros isn't supported for discovery?

Isn't this guesser name a bit weird?

/cc @ddeboer