Closed tommy-muehle closed 5 years ago
I'm -1 for that, as it forbids us to specify the supported Behat versions (meaning that changing our Behat requirement, be it for the upper or lower bound becomes a BC break)
Btw, as Behat must run some code in the same process than your project, using it as a phar can create very weird issue: if you have a Symfony 2.x project but the Behat phar ships with symfony/dependency-injection 3.x, the version of symfony/dependency-injection being used during the run of Behat is totally unknown (it could even be a mix of both, with some classes loaded from the phar and others from your project, which is likely to break both Behat and your tested code). Resolving dependencies compatible with both Behat and your other needs is a must have IMO, and this is achieved by installing Behat as a requirement in your project (a dev requirement of course, not a normal one)
Phar tools are good when they don't need to run in the same process than your code (static analysis tools for instance).
Are you installing this extension with composer, but then using Behat as a Phar?
To support this use we'd be better off making a Phar of the symfony extension, but as @stof points out, Phar is mostly for testing separate processes (e.g. browser automation)
Hi,
one dependency in this library is Behat itself. So I add always Behat (and all his dependencies) to my project dependencies. To avoid this I would prefer the use of the Behat PHAR file. For example via phar.io.
What do you think about removing Behat itself as a requirement and move it to the suggest section?
[EDIT] For example like the Symfony PHPUnit bridge which doesn't require PHPUnit but hook up.