[RFC] Renaming some core concepts... for the better

[fabpot]

I'd like to rename two concepts (with deprecation notices in 4.4 and full switch in 5.0): Symfony Environments and the Symfony
Profiler.

I know, they are core concepts, but I think it's time to reconsider their names. The impact will be huge in the docs, and our current users will probably hate us, but I think this is for the best going forward.

Symfony environments, why is it confusing?

We now manipulate environment variables everywhere in Symfony.
Most cloud providers also have environments.

You are testing the prod environment (the Symfony one) for your development
environment (local machine). See what I mean?

A Symfony environment is a way to switch the configuration to a different set of values: from dev to prod or the other way around. Or test.

I'd like to rename it to Symfony mode.

APP_ENV=prod to APP_MODE=prod

You are testing the prod mode on your development environment.

What about the Symfony Profiler?

I made the original mistake. A profiler is something very specific, like
XHProf, or Blackfire.

The Symfony profiler is not a profiler in the usual sense of the word. That's annoying and I keep bumping into people that do not understand the difference with Blackfire for instance.

There is also an inconsistency as we have a web debug toolbar, not a web
profiler toolbar. Another confusion, why is the name different?

I'd like to rename it to Symfony Inspector (was Symfony Debugger initially, but I changed my mind -- see comments below). I think it describes what it does best and also convey the notion that it should not be deployed in production. It is also the name used by browsers, so it matches well with our user expectations.

I know that this might seems pointless, but naming things correctly helps
developers understand the concepts.

WDYT?

[Pierstoval]

Symfony Mode

I would partly change this to "Kernel mode", because it would mean "Symfony" could be run in a certain "mode", but the actual behavior is related to the Kernel

Symfony Debugger

Totally okay wit this idea

[dunglas]

It makes perfect sense, current names are very confusing. Big 👍 on my side.

[dunglas]

@Pierstoval, it’s not only related to the kernel. Behaviors of API Platform, and Panther among other higher level things vary depending on the env.

[Pierstoval]

@dunglas:

@Pierstoval, it’s not only related to the kernel. Behaviors of API Platform, and Panther among other higher level things vary depending on the env.

There's a small grey zone then: application running in a certain mode ends up customizing the kernel mode.
"Symfony mode" is more user-friendly but doesn't clearly expose what it does, and it may confuse people in understanding Symfony is not always a "full-stack" framework.
"Kernel mode" is more low-level, but it clearly says what it does: change the mode in which the kernel is started.

Developers using Symfony already know what a Kernel is, and newcomers will eventually find it out while learning.

We could also rename it "Application mode", I think it might be a nice compromise, WDYT?

[fbnlsr]

The Symfony Debugger makes perfect sense imo. I'm using the debug bar so much that I never call it a Profiler.

As for renaming the environment, I personally think that's not a good idea. There's a reason that everyone is using the name "environment" when it comes to dev/test/prod. It's a convention that's used throughout the life of a project. And they are environments after all. Some things happen within a test environment, not a production one. I know that in the end it's just a name, but I think renaming the environment will make things confusing.

[javiereguiluz]

About environment -> mode, I don't feel like it's confusing using "prod/dev environment" + "env var" ... and most comparable techs use them without issues (Rails, NodeJS, Elixir, ExpressJS, etc.) But, it's true that the new name could avoid confusion to some people.

About profiler -> debugger ... I like it, but I also want to propose an alternative for your consideration: inspector. This tool is like the "inspector" included in browsers, a term that everybody already knows and uses (Chrome inspector, Firefox inspector, the web inspector ... Symfony inspector?)

[bobdenotter]

The timeline component in the current "profiler" can be considered an actual profiler, but as a whole, I'd agree debug seems better.

Same for environment -> mode: In my opinion this makes sense, and I assume it fits the mental model of novice developers much better.

[wouterj]

I don't have, apart from nostalgia, a strong opinion on Symfony environment/mode.

For Symfony Debugger, I'm on @javiereguiluz side: The tool is not really a debugger imho (that's something specific like Xdebug and should imho have features like breakpoints). I think Symfony Inspector or Symfony DevTools/Developer Tools (Chrome's official name) fits the feature-set better.

[fabpot]

I agree with Javier, Inspector is even better. And Wouter is right, we might confuse it with XDebug which would not be better than confusing it with a profiler.

[bnd170]

+1 with Javier, enviroment is not confusing name. But change Profiler by Debbuger is not a good idea imho.
Maybe DevTool/Developer Tools like wouterj said would be better.

[Mrkisha]

Inspector? Never heard anyone saying "open Chrome inspector", but I have heard million times "open Chrome devtoolbar". If we have to change the name, Symfony DevTools would make perfect sense to me.

As far as environment->mode is concerned, I think nothing should be changed. Its all about application environment rather than environment application is running on. Might as well call it Symfony Config if you really insist on changing the state of configuration rather than application environment.

[omissis]

I think I called env mode a few times already internally since Sf 2.0, so definitely +1 :)

[mazraara]

environment -> mode, seems good to avoid confusions.
profiler -> debugger, makes more sense to me and Inspector can be a much better name.

[drAlberT]

Aleluja aleluja @fabpot :)

As a sysadm I spend lot of time explaining my dev-users the difference among the different meanings of "ENV"! Big 👍 for me !

[fabpot]

Symfony itself is a developer tool, so renaming the profiling to devtools seems confusing to me and it does not really describe what it does.

[Pierstoval]

@Mrkisha About choosing a name, it's all about "Define {whatever name}". So "Define what devtools are" does not have a clear enough answer...
However, "Define inspector" 's answer is clearer: it's to inspect what's going on.

Also, "Symfony Config" is less clear: one would confuse the config folder and the "config mode" (again talking about "mode")

[stof]

I have one worry about renaming the environment to mode: we have a second (boolean) setting in the kernel that we call "debug mode" since the beginning. This would cause confusion.

A big +1 for Inspector though.

[luisfaceira]

I think this would be better discussed in two separate issues, one for environment and the other for profiler, since there are different reasoning and arguments to discuss in each case, and as already seen in a few comments, some people feel strongly about one and not the other, and vice-versa.

[chr-hertel]

I really like inspector +1

Maybe we could use "runtime mode" for dev/test/prod to distinguish from "debug mode"

[Pierstoval]

Debug mode has always been a bit confusing for people, even I sometimes have struggles to remember what it clearly does.

@luisfaceira:

I think this would be better discussed in two separate issues, one for environment and the other for profiler, since there are different reasoning and arguments to discuss in each case, and as already seen in a few comments, some people feel strongly about one and not the other, and vice-versa.

Well, many votes are in favor of "inspector" for profiler already 😉

[stunami]

big 👍from me environment to mode and one of the most confusing/awkward parts of the developer etc imho

You are testing the prod mode on your development environment.

Exactly! This is something I've always been saying to colleagues etc. It's confusing especially when environment variables were introduced.

Like Symfony Inspector definitely a better name of what it does

[nicolasbonnici]

Inspector rather than debugger, and i prefer the environment or staging to my point of view, same vocabulary as dotenv.

[luisfaceira]

For me it's very easy to agree that environment should be changed.

Not so much because of the confusion with environment variables (though, it is indirectly related), but due to the fact that it is fairly standard to have multiple deployments of a certain system, and its standard practice to refer to those different instantiated systems as "environments".

In that sense, when running locally in the developer workstation, it's usually called the dev (or local or even "John's") environment, independently of the front-router being called and the "APP_ENV" being used.
On the other hand, it's also not uncommon to access what many call a staging environment and there, for example, use "APP_ENV=prod".

I've seen many times the confusion of phrases such as "access the prod environment on the staging environment" or "use the prod environment on your local environment and you'll be able to replicate the bug".

So, just to be clear, big 👍 for renaming the environment concept to almost any new name that is chosen.

Regarding "mode", it seems like a good fit, I think it expresses better what it is and I can't instantly come up with any relevant concepts that would conflict with that.

[ogizanagi]

Not convinced myself it fits better, but what about runtime(-mode) or config? (after all, that's what is it, running an app with a specific config)

[Mrkisha]

@Pierstoval, my point is things are fine as they are.

[julienbourdeau]

I'm a big 👍 for Symfony Inspector.

But for Symfony mode, I understand how some people can confuse the two but I think the amount of work necessary is not worth the change. I think it's clear enough, to have env config matching your env.

As far as I can tell, all other frameworks call it Environment. So we're creating confusion for people coming from other communities.

[chr-hertel]

in my experience calling it "env" really creates confusion - even for teams with higher skill levels. some ending up with having additional envs like stage or qa because they try to match their infrastructure setup with symfony environments.
in trainings i already need to distinguish between symfony runtime environment, dotenv, env vars and server/infrastructure environment.

so a big +1 to rename env with sf5

[arkaitzgarro]

About environment -> mode, I don't feel like it's confusing using "prod/dev environment" + "env var" ... and most comparable techs use them without issues (Rails, NodeJS, Elixir, ExpressJS, etc.) But, it's true that the new name could avoid confusion to some people.

We use Rails and Express, and at some point it is confusing for developer to use RAILS_ENV and NODE_ENV to describe the mode the application runs, while deploying the applications to more than one environment like production, staging, test, dev... Internally we always call it dev mode or production mode, regardless the environment.

My two cents for something like APP_RUNTIME_MODE=prod.

[OskarStark]

Yes and you could have n compiled containers next to each other and run a specific one via this option

[ryden54]

@fabpot for environment, "app.presets" might be an explicit key as, as you said, it stands for a set of config values

[Aerendir]

Ok for renaming the profiler.

I’ve read all the comments about “environment”: I think there is still confusion in what each one of us thinks the word means.

Until we are all on the same path about the real meaning of the word, we will never come to a good name.

A good name is also related to what each one of us does with the “environment”: it happens I use it to test services that use prod configs (ands so, someone suggested to use the name “*_config”).

But I also know it have an impact on caching: so the word “mode” would be more appropriate.

There are other examples of other words used to describe a single aspect of what prod, test and dev do.

Anyway is clear that the term “environment” as used by Symfony is something different from the traditional meaning of the term that is, to me, the machine and it’s configuration: production environment is the “machine” that serves the app to the public, development environment is our computer, and so on with staging and test environments.

But thinking about all these things, it seems to me that all these changes that are caused by the value of the “environment” setting belongs all to the way Symfony behaves: more or less aggressive caching, use one config set instead of the other, etc.

It seems all related to the Symfony’s “behavior”/“behaviour”.

The only thing on which we all agree is changing the name of the profiler to Inspector (also if I prefer “devtools”: also if Symfony itself is a devtool, I say “open the devtools in Chrome”, not “open the inspector in Chrome”. But maybe it is simply that I'm not rigorous in calling the things with their own name).

+1 for the new mascotte for Inspector!

[gsylvestre]

lol 21 suggestions so far! @fabpot is like "oops what did i do!?"

• app_mode
• kernel mode
• symfony mode
• application mode
• mode
• symfony config
• config mode
• runtime mode
• staging
• runtime
• config
• app_runtime_mode
• stage
• selected_config
• active_config
• platform
• setup
• target
• app.presets
• env
• environment

Naming things is indeed complicated.

[teohhanhui]

I think APP_PROFILE makes sense, it's a profile which contains a set of configuration for the app.

Alternatives: APP_SUITE, APP_CONFIG_SET

[back-2-95]

Whatever gets selected, I think prefixing it with APP_ is still good.
It points to the fact that we're choosing how we run our app (regardless of the env).

[stunami]

I haven't seen anyone suggesting this.

APP_CONFIG

APP_CONFIG="prod" -> config/packages/prod

APP_CONFIG="dev" -> config/packages/dev -> config/services_dev.yml

APP_CONFIG simply defines what config to load which is essential what APP_ENV already but removes the overloading of the word environment;

There is no confusion about what environment is, and only what configuration is being used is defined. There is no link between APP_CONFIG and the environment where your app is running.

So maybe you like

• Use APP_CONFIG="prod" in your production environment
• Use APP_CONFIG="prod" in your stage environment
• Use APP_CONFIG="prod" on your dev environment to test your production config.

Or

• Use APP_CONFIG="prod" in your production environment
• Use APP_CONFIG="stage" in your stage environment

Both work and make sense, at least to me.

[teohhanhui]

APP_CONFIG simply defines what config to load

On a superficial level, yes, but kernel.environment could be used for anything, really.

[stunami]

APP_ENV -> APP_CONFIG is superficial yes but it does make more sense especially with the motivation.

A Symfony environment is a way to switch the configuration to a different set of values: from dev to prod or the other way around. Or test.

If you're talking internals then yes to remove/migrate away from the use of a key kernel parameter like kernel.environment won't be trivial as its used in many places but these things can of course be changed over time.

[javiereguiluz]

Here's another proposal to add it to the list 🙈 context (and APP_CONTEXT)

[teohhanhui]

@stunami I meant that on a superficial level it may seem that APP_ENV is only used to select which set of configuration to be used, but that's really not the case.

Also, kernel.environment is not internal. It could be used by any number of existing bundles and apps. Of course we could deprecate that, but making it internal would reduce its usefulness.

[Pierstoval]

Well, as @gsylvestre said, there's a lot of proposals for kernel.environment renaming. I think we should give that to the core team and let them decide, because everyone seem to have very different opinions 😄

[dkarlovi]

IMO "mode" is the best choice:

• environment clashes with several things, including "server environment" and "environment variables" (which this doesn't relate to)

So you assumed your Symfony environment is related to environment variables? What ever gave you that idea?

:)

• stage clashes with "deployment stage" (such as staging, test, production) which can intersect with the current environment, but doesn't exactly fit (example, both your staging and production deployments work in prod Symfony... er, environment)

Saying

Your staging deployment is running in prod mode using stg2 environment.

(named environment there being a set of environment variables, not directly managed by Symfony) sounds reasonable to me.

The only issue I see is debug, saying dev mode doesn't imply debug or vice versa, but saying

Running in debug mode.

feels natural.

[Mrkisha]

IMO "mode" is the best choice

Saying
Your staging deployment is running in prod mode using stg2 environment.

Sounds confusing at least. Staging deployment in prod mode using stg2 env? I pray this never comes to life!

[dkarlovi]

@Mrkisha that's exactly the level of complexity that's actually going on. Not having the words to tackle that complexity doesn't make it less complex, on the contrary. It's OK if the words sound confusing at first if they're well chosen, they'll survive. The first person to have said "hashtag" or "to tweet" surely didn't sound smart then. :)

To clarify:

Your staging deployment

Your application instance / deployment, the one I get when I access staging.example.com (as opposed to www.example.com)

is running in prod mode

is running in the same (Symfony) mode of operation (same config files loaded, basically) as the production deployment at www.example.com

using stg2 environment

using the prepared environment called stg2 (for example, you've changed your database DSN to point to a new, larger database cluster, or moving from AWS S3 to Azure Blob Storage, your original stg environment still points to the old setup), this type of "named environment variables" is very common when using public cloud providers or on Kubernetes, using a ConfigMap.

[juliusstoerrle]

Looking to other projects like Angular and Spring you always use a build config/configuration. I think APP_CONFIG would fit perfectly.

[Seb33300]

In all browsers, this is called Developer tools (See in browsers menu in toolbar), the inspector is just one of the features offered by the developer tools.

Inspector is the name used by Firefox, Chrome and Edge to inspect HTML code in the Developer tools.

[dkarlovi]

@Seb33300 it was clarified before
#34042 (comment)

[atompulse]

I just love it!
This idea just might be one of the best ideas since a long time, I like the APP_MODE
Good stuff @fabpot !

[ro0NL]

@dkarlovi i usually call this staging environment (D,T,A,P are all used for staging) vs application environment

so i'd say

Your "acceptance" staging environment serves/stages the "production" application environment

i think switching to e.g. "application mode" could work, but we need to think how to re-introduce kernel.environment, so each mode defines its "staging environment"

[stof]

i think switching to e.g. "application mode" could work, but we need to think how to re-introduce kernel.environment, so each mode defines its "staging environment"

@ro0NL kernel.environment is the app environment. There is nothing in Symfony parameters referencing the "staging environment" (btw, if you want to reuse the same deployment artifacts for each staging environment, you cannot have it as a DI parameter)

[Tobion]

@fabpot is this issue still relevant?

[fabpot]

I still think that both would be good. I've started to work on a PR to rename Profiler, and it would be a massive change, so not sure it's worth it. I need to check again to see if renaming only the UI and some user facing configuration would be enough and simple.

[nicolas-grekas]

About APP_MODE instead of APP_ENV, I tried in #37584. This is doable but I fear the cost will be too high for the community. We'll live with both names for years to come if we do it. I'd suggest abandoning this part of the proposal.