Description
the deprecation of the console flags --env and --no-debug have some bad sideffects:
- operation system compatibility is now much worse
- environment compatibility also has become worse
- multi environment usability is bad
all-in-all its a bad DX
- the compatibility with windows is awful with this change
i tested it locally with my symfony 3.4 app but it should make no difference in the case of passing env variables.
php bin/console --env=dev
Symfony 3.4.12 (kernel: src, env: dev, debug: true)
(fully working symfony console with no errors)
vs
APP_ENV=dev php bin\console
'APP_ENV' is not recognized as an internal or external command,
operable program or batch file.
vs
λ cmd /V /C "set APP_ENV=dev&& php bin\console"
[WARNING] Some commands could not be registered:
In EnvVarProcessor.php line 76:
Environment variable not found: "DATABASE_URL_LEGACY".
Symfony 3.4.12 (kernel: src, env: dev, debug: true)
---snip---
In EnvVarProcessor.php line 76:
Environment variable not found: "APP_SECRET".
so in fact, with this change the cli is broken on windows. of course a lot of people would say use bash but i also like diversity here, developer should have choices.
also the handy autocomplete possibility with clink on windows and bash-completion on linux is gone with this change. environment variables are cool but not the holy grail for everything. there is a reason for having flags on commands. imagine you have to call all commands like this:
URL=http://example.com RECURSIVE=true OUTPUT_FILE=foo.html wget
- developer & server environment
first we should keep in mind that we don't all have the same environment. we have different hoster, webservers and shells out there. not many are optimized for symfony. not everybody is using linux, not everybody has the ability to easily set env variables on their hoster, ...
as i switched to .env i really had a very bad experience with it. hashed/crypted passwords have a $ in them, passing them to php was horrible. it is the opposite of dry and escaping often is complicated. secret variables on gitlab can't easily be escaped https://gitlab.com/gitlab-org/gitlab-ce/issues/45173, nginx also has its quirks with env variables, and getting the env variables in bash wasn't straight forward (without puppet automation i really would have cried).
- multi-environment DX is bad
having a 2nd entry point to quickly use the debug bar on the production server is really very helpful. so multi-environment is nothig we don't use out there. i wouldn't say its uncommon. clearing cache for both environments then gets cumbersome and we are back of having shell scripts or task runner in our project which abstract our now complicated calls.
there are many deprecations i understand, sometimes it is necessary to force user/developer to go in a certain direction. for example, i think its really good to drop the base controller to force the dependency injection. many applications out there are forcing in a specific direction. often this is good but in the last year i noticed that the enforcement in specific directions is too strong and restictive. for example .dev domain hardcoded to https in chrome and firefox, firefox drop of legacy extensions, force to require php 7.2 in a lib which simply does not require it, force to upgrade software to major versions in each release without a LTS, all interfaces are getting simpler and simpler and advanced user are denied to setup their app as they want (i remember icq, the interface was simple but there was a advanced mode), ...
we are all humans, we all have limited time, if enforcement is stealing our time and forces us to build workarounds to archive what we already have, maybe then the enforcement was not the right one.
we are software architects, we can find a lot of analogies with architects but in as software architects we have the luxery that we don't need to decide if we want a flat roof or a pitched roof, we work virtual and simply can have both. its a good feature to read settings from the env but it is even better if i can simply override it with a human readable command.
in my wget example from above we can run wget and rely on the correct env setting. which is quite sure for a automated run but if i log in with my user and forget to do a su my complete settings are wrong. as soon as i have user interaction i really prefer to provide parameters.
this is too much pain for no real gain. why removing a handy feature?
also see: