Implemented extra.symfony.env in composer.json

[SerheyDolgushev]

This PR provides an option to set environment variables on packages installation, in the same way as recipes.env does.

And it might be very handy for small packages, which do not have Symfony Recipes.

Example usage in composer.json:

{
    ...
    "extra": {
        "symfony": {
            "env": {
                "VAR_1": "value1",
                "VAR_2": "value2"
            }
        }
    }
}

[SerheyDolgushev]

@fabpot and @nicolas-grekas could you please review this and confirm it is a valid idea? And if so, I`ll work on the tests for this PR.

[fabpot]

As said before, as soon as a recipe cannot be auto-installed, a recipe must be created. Configuring a recipe via composer.json has been rejected many times now. And in any way, if it would happen, we would have to support everything, not just one configuration. 👎 for me

[SerheyDolgushev]

Sorry, I wasn't involved in previous discussions about configuring the recipe via composer.json. So I might miss some important points there. But I would assume they took place before #612 was merged. And I would like to provide my perspective on this PR. @fabpot Please point me out where I am missing something.

I`ll just try to describe the abstract case for this PR to make it as much common as possible.

So let's say there is vendor/cool-feature package. It is a Symfony bundle, and it depends on some environment variables. It is designed to be used in some specific projects, let's say vendor/cms. The vendor/cms project does provide a set of the scripts which are triggered on post-install-cmd and post-update-cmd composer command events:

• clearing the cache
• compile assets
• build translation files
• etc

Installing the package without flex recipe

So right now the flow to install vendor/cool-feature package is:

1. Require package via composer:

   • bundles will be enabled because of auto-discovery
   • post-install-cmd scripts will be triggered, and there might be some errors triggered because of missing vendor/cool-feature specific environment variables

2. Add vendor/cool-feature specific environment variables into .env/.env.local/etc.

3. Manually run commands from post-install-cmd.

So some manual steps are required in this scenario, which needs to be included in the installation documentation. It might be optimized by using flex recipe.

Installing the package with flex recipe

As an option, a flex recipe can be submitted for vendor/cool-feature. Per my understanding, it will be manually validated and approved. Afterward, the installation flow would be:

1. Require package via composer:
   • Specified bundles (from the flex recipe) will be enabled
   • Specified environment variables (from the flex recipe) will be added to .env
   • post-install-cmd scripts will be triggered and no errors would be expected

This scenario is much better, as it does not require any manual steps during the package installation. But it requires manually submitting the flex recipe and somebody needs to review and validate it. Which is not the case for popular packages. But it might not worth reviewers times on the recipes for non-popular bundles with few dozens of installs.

This PR

The main goal for this PR is to provide a way to automate small packages installation. And I`m not sure if all recipes configurations should be supported in the composer. But if that is the only thing that prevents it from being merged, we can easily fix it.

Also, I don't see any obvious downsides in this PR, but only upsides:

• it allows using some of Symfony flex magic in a simpler way
• it saves recipe reviewers time
• it will save a lot of developers time as no more manual actions will be required to install the packages

But most likely I`m missing anything? Please let me know if my context is not counting for some major aspects.

[nicolas-grekas]

manually submitting the flex recipe and somebody needs to review and validate it

This step is really fine: done once, used many times.T hat's what the recipe system is based on.
Having reviewers spend some time on this is desired as a means to improve the overall quality of recipes.

Thanks for proposing. As @fabpot wrote, we're going to stick with the current policy.