[RFC] Config file

[malarzm]

Currently the only way to configure how Paraunit should behave is to add CLI flags to the command, which is great because it's simple. It would be however awesome to have a config file (like other tools do) which then could be overridden by CLI options. The config would be passed to the command with -c|--configuration like vendor/bin/paraunit -c paraunit.yaml (or any other format you prefer). Paraunit could also be actively looking for the config file, i.e. use it if present, but that's a detail. The file would look like a standard Symfony DI config file:

parameters:
    # whatever one could pass via CLI arguments could be here as well

services:
    App\Extension\Paraunit\CustomChunker: ~

    Paraunit\Runner\TestChunkerInterface: '@App\Extension\Paraunit\CustomChunker`

Services part should work pretty well when paraunit is installed through composer as it'll use app's autoloader. I am not sure about PHARs though.

What do you guys think?

[Jean85]

Opening the internal DI container like this seems too wide of an access to me: it may lead to errors and more work as a maintainers, since it has a VERY wide API surface.

I would prefer a smaller entry point. Maybe still a configuration file, but I would be unsure on the format. Also, the -c|--configuration option is already in use and proxied to PHPUnit right now...

[malarzm]

Opening the internal DI container like this seems too wide of an access to me: it may lead to errors and more work as a maintainers, since it has a VERY wide API surface.

I admit I used it mostly as a quick win for defining userland services and having them in the container already. I was afraid this will come up and I totally understand :)

I would prefer a smaller entry point. Maybe still a configuration file, but I would be unsure on the format.

We could take a page from Symfony's extension playbook and have a configuration similar like bundles do. I am not sure though how to allow user define their own services meant to replace/decorate specific parts of Paraunit.

Also, the -c|--configuration option is already in use and proxied to PHPUnit right now...

Good point. Let's say it's also a detail which can be figured out later.

[Jean85]

I am not sure though how to allow user define their own services meant to replace/decorate specific parts of Paraunit.

We could simply expect a YAML/XML config file that has a very specific option. The class name could still be a good choice, even if it could be limiting in terms of DI.

[malarzm]

Without exposing DI the config looks less useful, the same can be achieved with passing FQCNs as CLI options. Not saying it won't be handy, it'd make our lifes easier anyway, just not fully solving the problem I hoped it would :)

I'll try to adapt #164 this week to have FQCN configurable from CLI and see what sanity-checks will emerge from this. I'm leaning towards runtime check for no required arguments in __construct or just adding the FQCN to DI and hoping it'll be autowired.