allow symfony/options-resolver:^2.6 as dependency

[nlegoff]

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
License	MIT

What's in this PR?

Allow lower version of symfony/options-resolver

Why?

Hello, I'm working at Blablacar and our PHP monolith is still running on Symfony 2.8.x.

We are working pieces by pieces on migrating to 3.x but believe me it is not an easy task.

In the meantime, not allowing options-resolver 2.x prevent us from integrating a various numbers of internal php sdk that are already using httplug 2.x abstraction.

Therefore I was was wondering if there was a specific reason for preventing the use of options-resolver 2.x and removing it in httplug 2.x (it was previously authorised in httplug 1.x)?

There is no incompatibility issue (CHANGELOG) preventing its use.

Thanks.

[GrahamCampbell]

Why not just use php-http 1.x if you are on Symfony 2.x. Symfony 2.x won't work on the newest PHP anyway... it only works up to PHP 7.2.

[nlegoff]

Hello Graham,

Thanks, for your reply.

Symfony 2.x won't work on the newest PHP anyway... it only works up to PHP 7.2.

We are currently running on php 7.3.11 (it's a Symfony app with more than 600K lines of PHP code (without counting vendors)). There is nothing preventing Symfony 2.x to run on PHP 7.2 or higher versions. Your assertion is wrong.

Why not just use php-http 1.x if you are on Symfony 2.x

We are moving our architecture from a monolith to services.
We have therefore extracted many features of monolith to new services that are operated by new teams and most of those services are using either:

• PHP with Symfony 4.4 as framework and running on latest php7.4
• JAVA with spring boot as framework and running on JAVA corretto 11

Anyway since we are living in a PHP/JAVA world, we decided that those teams should provide their respective JAVA&PHP SDK.

For PHP we decided to follow PSR-18 standard and they choose HTTPlug for abstractions.
PSR-18 is provided by HTTPlug 2.x.

Requiring their PHP SDK in our monolith to reach their services is therefore impossible.

Here is a summary of composer

php -d "memory_limit=-1" /usr/local/bin/composer require blablacar/communication-service-sdk:~1.0 --ignore-platform-reqs
Warning: Accessing satis.blbl.cr over http which is an insecure protocol.
...
  Problem 1
    - Conclusion: don't install php-http/httplug v1.1.0
    - Conclusion: remove symfony/symfony v2.8.52
    - Conclusion: don't install symfony/symfony v2.8.52
    - Installation request for blablacar/communication-service-sdk ~1.0 -> satisfiable by blablacar/communication-service-sdk[1.0].
    - php-http/client-common 2.0.0 requires symfony/options-resolver  ^3.4.20 || ^4.0.15 || ^4.1.9 || ^4.2.1 -> satisfiable by symfony/symfony[3.4.x-dev, 4.0.x-dev, 4.1.x-dev, 4.2.x-dev, 4.3.x-dev, 4.4.x-dev]
    - php-http/client-common 2.1.x-dev requires symfony/options-resolver  ^3.4.20 || ~4.0.15 || ~4.1.9 || ^4.2.1 || ^5.0 -> satisfiable by symfony/symfony[3.4.x-dev, 4.0.x-dev, 4.1.x-dev, 4.2.x-dev, 4.3.x-dev, 4.4.x-dev, 5.0.x-dev, 5.1.x-dev], symfony/options-resolver[3.4.x-dev, 4.0.x-dev, 4.1.x-dev, 4.2.x-dev, 4.3.x-dev, 4.4.x-dev, 5.0.x-dev, 5.1.x-dev, v3.4.20, v3.4.21, v3.4.22, v3.4.23, v3.4.24, v3.4.25, v3.4.26, v3.4.27, v3.4.28, v3.4.29, v3.4.30, v3.4.31, v3.4.32, v3.4.33, v3.4.34, v3.4.35, v3.4.36, v3.4.37, v3.4.38, v4.0.15, v4.1.10, v4.1.11, v4.1.12, v4.1.9, v4.2.1, v4.2.10, v4.2.11, v4.2.12, v4.2.2, v4.2.3, v4.2.4, v4.2.5, v4.2.6, v4.2.7, v4.2.8, v4.2.9, v4.3.0, v4.3.0-BETA1, v4.3.0-BETA2, v4.3.0-RC1, v4.3.1, v4.3.10, v4.3.11, v4.3.2, v4.3.3, v4.3.4, v4.3.5, v4.3.6, v4.3.7, v4.3.8, v4.3.9, v4.4.0, v4.4.0-BETA1, v4.4.0-BETA2, v4.4.0-RC1, v4.4.1, v4.4.2, v4.4.3, v4.4.4, v4.4.5, v5.0.0, v5.0.0-BETA1, v5.0.0-BETA2, v5.0.0-RC1, v5.0.1, v5.0.2, v5.0.3, v5.0.4, v5.0.5].
 ...
    - Can only install one of: symfony/symfony[3.4.x-dev, v2.8.52].
    - Can only install one of: symfony/symfony[4.0.x-dev, v2.8.52].
    - Can only install one of: symfony/symfony[4.1.x-dev, v2.8.52].
    - Can only install one of: symfony/symfony[4.2.x-dev, v2.8.52].
    - Can only install one of: symfony/symfony[4.3.x-dev, v2.8.52].
    - Can only install one of: symfony/symfony[4.4.x-dev, v2.8.52].
    - Can only install one of: symfony/symfony[5.0.x-dev, v2.8.52].
    - Can only install one of: symfony/symfony[5.1.x-dev, v2.8.52].
    - don't install symfony/options-resolver v3.4.20|don't install symfony/symfony v2.8.52
...
    - don't install symfony/options-resolver v5.0.5|don't install symfony/symfony v2.8.52
    - Installation request for symfony/symfony (locked at v2.8.52, required as 2.8.*) -> satisfiable by symfony/symfony[v2.8.52].
    - Conclusion: install php-http/httplug v1.1.0|install php-http/client-common 2.0.0|install php-http/client-common 2.0.0-RC1|install php-http/client-common 2.1.0|install php-http/client-common 2.1.x-dev

Installation failed, reverting ./composer.json to its original content.

Considering the very basic usage of option resolver package to resolve plugins options made by client-common package, my question is:

What is the rational behind the removal of the options-resolver 2.x package in HTTPlug 2.x?

If there is no legitimate reason would you consider allowing the use of the 2.x options resolver package?

Again thanks for taking time to answer me and thanks for the time you spend on working on this indispensable project for interoperability.

[dbu]

i see your reasoning, and as options-resolver seems quite stable, i don't see a problem in allowing an older version.
most users won't be affected by this change as they use newer versions.

[GrahamCampbell]

Your assertion is wrong.

There are loads of known bugs in Symfony 2 that only occur in PHP 7.3 and 7.4.

[GrahamCampbell]

They only test Symfony 2 up to PHP 7.2. In order to Symfony 3 to work on PHP 7.3 and 7.4, LOTS of changes were needed.

[dbu]

true that. but if it works for them, all the better. and afaik options resolver really does not do anything fancy that breaks with php versions.