Flex: Make Flex more Granular ?

[DavG]

Hello,

Flex is great, but honestly, it is a little too magic sometimes. I mean, really.

Flex is trying to force me to adopt some practices I dont want to.
For example, I use "real" environment variables, in all environment.
So, I don't use Dotenv. And I like that Symfony doesn't force me to.
But, Flex will create/update a .env.dist file.
Same with phpunit.xml.dist.
What if I have real env var ?
What if I use another environment variable naming convention ?
That was supposed to speed up things, but for me, it's a slow down.

So, firstly, I think we should be able to tell Flex "ignore this recipe part" (.env.dist)
In this special case, maybe this could be automatical ; Flex could check if Dotenv is installed.

Secondly, the recipe part, in general, should be disabled in non-dev environment.
Ok, theoricaly, if you commit well your symfony.lock , recipes will do nothing in prod. But it seems dangerous to me.

Maybe the best option would be to split the package in 2 parts :

• symfony/flex (for all env, in "require"): symfony scripts, composer parallel downloads, etc.
• symfony/flex-dev (dev only, in "require-dev") : all about helping developers, so recipes goes here.

I don't get why recipe code should be on the production server.

What do you think, @fabpot ?

Thanks.

[Pierstoval]

What if I have real env var ?

You can disable DotEnv lines in config/bootstrap.php. But even then, if you already have real env vars, DotEnv doesn't override existing vars, so you're safe anyway.

What if I use another environment variable naming convention ?

Change var names, after all they're yours once they're added to your projects 🙂
The current var names are just basic conventions that suit most projects, but if it's not the case for yours, you can change it.

Maybe the best option would be to split the package in 2 parts :

• symfony/flex (for all env, in "require"): symfony scripts, composer parallel downloads, etc.
• symfony/flex-dev (dev only, in "require-dev") : all about helping developers, so recipes goes here.

Seems like it'll introduce way too much maintenance from the team and it would not really be useful for DX. What I see here is that you need to disable "some parts" of the Flex package configuration automation, not Flex itself.

Something that could be introduced in Flex, maybe, is a extra.symfony.disable-configurators array option in order for you to be able to disable the env configurator, as well as other configurators (like copy-from-recipe if you want to almost completely disable the recipes system).

I don't see any more straightforward flex-related option for your case.

Let's wait for other comments 🙂

[DavG]

Change var names, after all they're yours once they're added to your projects 🙂
The current var names are just basic conventions that suit most projects, but if it's not the case for yours, you can change it.

Of course, but that's my point.
If I already know, in advance, that I don't want Flex to configure my env-var, why should I lose time by manually canceling the recipe ?

"Flex is about to help developers"

Something that could be introduced in Flex, maybe, is a extra.symfony.disable-configurators array option in order for you to be able to disable the env configurator, as well as other configurators (like copy-from-recipe if you want to almost completely disable the recipes system).

Yes, I would like an option like that 👍

Seems like it'll introduce way too much maintenance from the team and it would not really be useful for DX. What I see here is that you need to disable "some parts" of the Flex package configuration automation, not Flex itself.

Yes, in dev, I would like to disable the env-var configuration automation.
In prod, I would like to disable all the recipe feature.

Just another example. There are many issues here about problems with symfony.lock , miss committed, project started before the .lock was introduced, etc.

That was our case a few weeks ago.
We deploy in prod a new app, and because of an error with the symfony.lock, Flex add a .yaml (containing non-existing env-var), and the "cache:clear" fails. Everything was working well on dev.

That's seems dangerous to me, the app shouldn't change itself in prod.
And that's obviously not compatible with read-only filesystem.

Of course, you can answer me, "fix your symfony.lock and commit it", but the mistake is easy.
Even without splitting the package in 2 parts, I really believe the recipe feature should be totally disabled in non-dev environment.

[stof]

I really believe the recipe feature should be totally disabled in non-dev environment.

that would still require to disable it (as guessing whether it is a dev or non-dev environment would be a nightmare), which is as easy to forget that committing the symfony.lock file (and maybe even easier).

[apfelbox]

That's seems dangerous to me, the app shouldn't change itself in prod.

Couldn't you just install flex as dev dependency in composer?

[stof]

@apfelbox that won't work for @auto-scripts, as that one needs to run in prod too.
that would be the advantage of splitting Flex into 2 composer plugins (one running auto-scripts, and maybe implementing the parallel downloaded, and another one providing the Flex developer experience)

[Pierstoval]

If I already know, in advance, that I don't want Flex to configure my env-var, why should I lose time by manually canceling the recipe ?

"Flex is about to help developers"

And you're right!

With the old Symfony Installer, you would have had to remove all unnecessary packages, change parameters.yml to inject your env vars, etc., so at least Flex allows you to come to this point much faster than before by not taking the config in account and just install a project & check env vars.

Yes, in dev, I would like to disable the env-var configuration automation.
In prod, I would like to disable all the recipe feature.

Nothing should happen in prod since you should be only doing composer install --no-dev --optimize-autoloader or something similar, and according to symfony.lock, no recipe will be configured.

Just another example. There are many issues here about problems with symfony.lock , miss committed, project started before the .lock was introduced, etc.

This should never happen anymore, especially after a composer update or composer sync --force (that'll be coming in next version). Any new project will use the correct workflow, and it's straightforward to upgrade 👍

That was our case a few weeks ago.
We deploy in prod a new app, and because of an error with the symfony.lock, Flex add a .yaml (containing non-existing env-var), and the "cache:clear" fails. Everything was working well on dev.

This probably means that you didn't composer update for a long time, maybe you should consider upgrading your dependencies a bit more often 😉. It depends on the projects, but I suggest once every month should be sustainable enough for most projects 👍

Even without splitting the package in 2 parts, I really believe the recipe feature should be totally disabled in non-dev environment.

Flex can't know anything about dev or non-dev environment. Flex is a package configurator distributed as a composer plugin, not a project manager or a deployer. As said above, it shouldn't do anything unless you require or remove a package, which is not something you do on production machines at all.

[BoShurik]

Maybe it would be useful for deploy to have option --disable-recipes so composer install --disable-recipes does not apply recipes

[DavG]

With the old Symfony Installer, you would have had to remove all unnecessary packages, change parameters.yml to inject your env vars, etc., so at least Flex allows you to come to this point much faster than before by not taking the config in account and just install a project & check env vars.

There are multiple use-cases.
Of course, you're right when starting a new project.
But on an existing project, in my case, Flex is slowing down me.

I just want a way to tell Flex to not do too much.
Sounds reasonable to me.

This should never happen anymore, especially after a composer update or composer sync --force (that'll be coming in next version). Any new project will use the correct workflow, and it's straightforward to upgrade 👍

Yes. This should...

Flex can't know anything about dev or non-dev environment.

That's why I believe the splitting of the plugin is the cleanest and the most logical solution.

[Pierstoval]

That's why I believe the splitting of the plugin is the cleanest and the most logical solution.

Yes, and for your use case, you ask the maintainers to break the workflow of all other apps 😕 Especially when you could just composer update symfony/flex and re-etablish a proper workflow

[DavG]

Yes, and for your use case, you ask the maintainers to break the workflow of all other apps 😕 Especially when you could just composer update symfony/flex and re-etablish a proper workflow

I'm not asking. I give you a feedback.
We can work with Flex. It slows us down a bit. But that's not the end of the world.

Don't say it's my use case. Env Var was just an example. There are many reasons people can legitly wants to disable (some) recipes..

Flex should be.. flexible, no?
Symfony is very modular, splitted in little repository/component... so why not Flex ?

[Pierstoval]

Symfony is very modular, splitted in little repository/component... so why not Flex ?

I guess it's because there are at least 150 releases per month for the components to manage, plus all the PRs and issues that come up every day on the framework, therefore keeping Flex simple for everyone might be a much better alternative than splitting it in more packages?

I totally understand the points you expose here, it's just that I don't think that Flex should be _that_ flexible.

However, having a parameter to disable a configurator could be a nice option, if it's accepted by the core team 🙂

I imagine some config like this, for now:

// composer.json
{
    // ...
    "extra": {
        "symfony": {
            // Simple and general:
            "disabled-configurators": ["env", "copy-from-recipe"],

            // Complex but... granular:
            "disabled-flex-packages": {
                "vendor/package-name": ["env", "copy-from-recipe"],
                "another/package": ["*"]
            },
        }
    }
}

Could be interesting. If such package is detected, disable associated configurators.

This would definitely be granular and it would fix your issues 👍

[DavG]

That would be perfect.

(The simple and general would be enough for me, but I cant tell for other people).