[Proposal] Paraunit configuration with dotEnv

[facile-it]

[Proposal] Paraunit configuration with dotEnv

[Jean85]

I need to look deeper into this, I don't know dotEnv well enough. This could substitute the SF Config component as a dep?

@ranpafin what do you think about this?

[Algatux]

@Jean85 I meant this as project test env configuration, it simply can't substitute the sf config.
Using env variables makes easy porting paraunit from local to CI envs configuring secific parameters for each one (process number, phpunit xml path, and future parameters that actually are only triggered with the commandline).
IMHO I think it can be an optional configuration method that allows optimizing paraunit for the env actually in use without the needing of additional configuration files

[Jean85]

I wasn't talking of the SF configuration of the project under test, but the SF Config component that it's a dependency of Paraunit right now..

[Algatux]

@Jean85 yes what I was saying in my manner :P, dotenv can't replace the component.

[ranpafin]

@Algatux what configuration are you planning to move in the .env?

As @Jean85 reported we're using the config component . I would expect that when the need arises to have additional configuration, to find such configuration in a file that can be parsed with the config component.
Moreover since we're using the dependency injection component as well, any parameter we load inside the container can be used for injection purposes.
So basically i see the need for an enviroment-specific configuration, maybe your CI machine have different number of processor than the your local machine and may need to be fine-tuned so i think we should proceed with the parametrization but I also think (correct me here if i'm wrong) that we can achieve the 100% of this configuration needs using the config component.
To put it more bluntly i have the feeling that the responsibility of the config component and the .env are overlapping.

[Algatux]

@ranpafin you are totally right, the same configuration needings can be achieved only using the symfony config component. The differences, in my opinion are:

1. totally separate the environment from the package configuration
2. avoid multiple configuration files like paraunit.yml/xml in the user project root

About DI I was thinking to convert the config.php file to a service to inject where needed

[Jean85]

Sorry that the #24 PR got closed.

BTW, I was thinking about integrating this feature, but I'll need to complete the coverage feature first. In the relative branch I've changed approach: the Symfony DI is built inside the command, since I want to inject the CLI options as container parameters. This allows me to personalize the experience without injecting state in all the services and listeners.

If we merge together this approach and the .env feature, we could create a cascading hierarchy of inputs:

• first level is the defaults: the values that are defined in the .yml definition files of the DI
• second level would be the .env: if a matching value is defined, it will overwrite the default of the YML files
• third (and last) level would be the CLI: if something is specified in the command line, it should take the precedence over all other settings

What do you think about it?

[Algatux]

Exactly what I was thinking closing that PR.
I think that there can be an additional level to take in consideration, a "project" yml configuration.

so:

1. defaults
2. .env:
3. project yml
4. CLI

too much ?

[ranpafin]

@Jean85 @Algatux
Considering the project is moving away from symfony "bundling" logic and only rely on components it could make sense to use an external configuration.

The hierarchical approach LGTM i would suggest a different idea for the second level:

Use phpdotenv library will require a developer to adopt such strategy to handle environmental and external configuration.
While it's a pretty solid approach someone may want to use different methods to configure libraries. Particularly Symfony users tend to rely on the combination of DI/Config components and seldom adopt the phpdotenv.
Another thing to consider is that all the configuration of Paraunit contains non-sensible data that can be easily committed to version control without breaking any security boundary.

So my idea would be to use the phpunit.xml configuration file. Every Paraunit user is also a phpunit user and the configuration file will always be available without the need to include any external library or change env handling approach. Also both configuration are logically connected. Finally we already parse the configuration file and it could be trivial to extract additional data.

[Jean85]

I'm not sure about the phpunit.xml file: we may break compatibility with PHPUnit easily, since it follows a formatting strategy that is out of our control, and secondly we parse it using directly the PHPUnit classes, so extracting additional information is not so straightforward.

On the per-project argument, I thought that .env files were per-project, and not per-environment... I need to know more about it.

[Algatux]

.env file is used on development env to emulate Environment variables via phpdotenv. on a CI or (not our case) production environment the .env file must not be present.

[Jean85]

So you're telling me that using .env or an environment variable is the same, right?
At this point, we should only suggest .env as an alternative mean to set environment variables project-wise.

If, as an example, I use a container for my dev environment, I can set those in my Dockerfile, and I'll have them ready to use!

[ranpafin]

@Algatux yes, usually CI tools have their own way to set environments. Travis for example have an apposite section!

I was thinking something along this lines:

<paraunit>
    <max-process-number>10</max-process-number>
</paraunit>

As far as i know, but it may be worth looking into phpunit allow for custom configuration and just ignore tags that are not in the documentation.

Alternately phpunit allow for custom env parameters in the "php" tag:

<php>
    <env name="max-process-number" value="10"/>
</php>

[Jean85]

Ok, so maybe we should just try if PHPUnit rejects the XML if it contains unknown (for it) tags.
Between the two approaches, I would prefer the first one, with the <paraunit> tag. This could solve the issue of separating the config between environments or CI, a different XML would carry different settings.

[Jean85]

No movement here, this issue is stale. Closing, if someone has code, a PR for review is still welcome.