I have been reading up on the symfony 3.3 dependency injection container. This pr uses some of the new features and makes the container pre compiled, which makes execution much faster. The behat feature tests are now 40-50% faster. A great asset when the test suite grows... It also makes us ready for when symfony 4 is released later this year.
A problem though is injecting dynamic parameters into a compiled container. The only way I have found to do this is by setting an environment variable before constructing the container. Poor OOP in other words. Have a look at line 87 of Console/CommandWrapper.
The putenv call is neccesary to support the --path option and the default user dir of $HOME/.giroapp that I have been insisting on. The need to call putenv however makes me question myself. Maybe we could just read GIROAPP_PATH and default to something silly like a directory named giroapp in the current working dir..??
I have been reading up on the symfony 3.3 dependency injection container. This pr uses some of the new features and makes the container pre compiled, which makes execution much faster. The behat feature tests are now 40-50% faster. A great asset when the test suite grows... It also makes us ready for when symfony 4 is released later this year.
A problem though is injecting dynamic parameters into a compiled container. The only way I have found to do this is by setting an environment variable before constructing the container. Poor OOP in other words. Have a look at line 87 of
Console/CommandWrapper
.The
putenv
call is neccesary to support the--path
option and the default user dir of$HOME/.giroapp
that I have been insisting on. The need to callputenv
however makes me question myself. Maybe we could just readGIROAPP_PATH
and default to something silly like a directory namedgiroapp
in the current working dir..??Any suggestions @nonbinary?