Make puli optional

[sagikazarmark]

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.

[dbu]

hm, indeed having autodiscovery for just guzzle and maybe 1 or 2 very common other ways we know about and use puli for possibly unknown 3rd party implementations seems like a good idea to me. i would keep the order: check if we have puli, if we do use it. only then do the simplified check. the other way round, there would be no way to use puli if you happen to have one of our known implementations laying around in the codebase

[sagikazarmark]

Should it be in a new minor release?

It is not a patch, but doesn't break BC and many libs rely on ^0.8

[dbu]

i think minor release is fine, as long as we keep using puli if its available, to not trip up existing applications that rely on puli.

[Nyholm]

I like the idea of making Puli optional. It will make it easier to get started with Httplug.
I've created a PR #58, but when I started to think about that PR I was not convinced that the solution was good enough. I created a second PR #59 which I like much more.