Symfony: [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 :+1: 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.

[bertoost]

Makes perfect sense to me 👍

[phillylovepark]

I like Symfony Inspector more than Debugger, good idea.

I found Symfony mode alright but not fitting perfectly. What about Symfony state ?

[Devristo]

In my opinion mode is better than env, however still a bit vague? I'd say APP_ENV determines more which config is used than its parameters (which are defined in the environment).

What about APP_CONFIG or KERNEL_CONFIG ? Like this its value corresponds exactly to the folder / files used in the config folder.

[jadelrab]

Symfony inspector is way fitting than debugger or profiler.

For Symfony mode I think it is not the right choice, it is a configuration profile more than a mode

[linaori]

In my opinion mode is better than env, however still a bit vague? I'd say APP_ENV determines more which config is used than its parameters (which are defined in the environment).

What about APP_CONFIG or KERNEL_CONFIG ? Like this its value corresponds exactly to the folder / files used in the config folder.

I personally would be okay with APP_MODE, though I do understand it to be a bit vague. A few more options:

• CONFIG_MODE - because you set the config to a specific mode
• KERNEL_MODE - because it's primarily how the kernel compiles the container and what config it loads
• CONFIG_NAME - because in the end, you load a config by name
• SELECTED_CONFIG - because in the end, you select a config

I'd like to rename it to Symfony Inspector

:+1: I like it a lot!

---

Thank you Fabien! Especially the environment name is something that I had to keep explaining to people. At my current company they also configured it to be identical to server environments. This causes more issues than needed.

As long time Symfony developer and supporter on IRC/Slack, I fully support these much needed changes!

[stunami]

Though a bit more about this...

APP_ENV=prod to APP_MODE=prod

Should/canAPP_DEBUG be incorporated into APP_MODE? And the debug flag just becomes a configuration option for the mode.

mode = config + debug perhaps

For me it is just part of mode but the debug flag is used quite early on when the kernel boots so it may need to stay separate.

[linaori]

I've never really understood why debug is a separate flag to be honest. I think it would simplify if you had a different application mode + config for debug, rather than a flag.

[nicolas-grekas]

Debug is a separate flag because the env-name is an opaque string, so "debug" cannot be inferred from "dev" or "prod" because those can be "whatever".

[linaori]

I've personally never used the debug flag other than having it off in prod and on in dev. As far as I know, it would require a compilation of the kernel in order to work properly. While "debug" cannot be inferred, do we really have to?

Does it make sense to (runtime) change production to use debug? Does it make sense to locally use dev without debug? To me prod means without debug and dev with debug. Then you have any other custom environments (or non-standardized), they could either configure, or not configure debug to be active.

From what I can tell, the majority of debug depending code, is for the kernel.debug parameter. This enables not necessarily debugging code, but primarily profiling and inspection code. What if instead of accepting it as a flag for the kernel, this is nothing more than a setting in your config under the "InspectionBundle" for example?

[back-2-95]

What a timing for the question =)

I was just staring settings for Drupal 8 project (Symfony based) and thinking how to structure configuration related to environments, for example:

• database settings are per APP_ENV (local Docker, AWS, Azure, Openshift etc)
• cache settings are per APP_MODE
• debug settings per APP_MODE
• CDN settings are per APP_ENV as related to domain
• paths to file folders (e.g. user uploads) are per APP_ENV

And I still want to have a possibility to use combination like
APP_MODE=dev in APP_ENV=test|production

[OskarStark]

👍 for Symfony Inspector
👍 for mode

[javiereguiluz]

Debug is a separate flag because the env-name is an opaque string, so "debug" cannot be inferred from "dev" or "prod" because those can be "whatever".

Just asking: couldn't we define a parameter called debug (false by default) and set it in the config of each environment/mode?

# config/services.yaml
parameters:
    locale: 'en'
    debug: false
    # ...

# config/services_prod.yaml
parameters:
    debug: false
    # ...

# config/services_dev.yaml
parameters:
    debug: true
    # ...

[yceruto]

:+1: for APP_MODE and Symfony Inspector.

About the APP_DEBUG flag, it's a Kernel argument that has a mean even before loading any config, it cannot be removed or inferred from the app env.

[dkarlovi]

:+1: for env => mode, this becomes apparent in Sentry where you want to see what the app instance is (prod, staging, etc), but your staging instance is probably also using Symfony's prod mode (that's the whole point of staging, be as close as possible to prod), you'd get prod from both.

Not being able to use APP_ENV as the application environment there was a head scratcher. :laughing:

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

This is an opportunity to rename the toolbar too, it can be the "inspector toolbar" or similar.

Symfony inspector

This is an opportunity for a new mascot! :)

[JonNiola]

APP_MODE makes perfect sense to me as does Symfony Inspector. Both changes improve the accuracy of the lexicon.

[hhamon]

I honestly don't like the word mode as it's too vague to me. It's as vague as a word like context for instance.

I would follow some others' recommendations such as "runtime mode" / "runtime config".

I agree Inspector seems much better :+1:

[hhamon]

What about stage instead of environment|mode?

[Pierstoval]

stage is interesting but I think it's not really obvious to newcomers 😕

[drAlberT]

stage is related to the deployment .. is confusing the same way it is ENV
today

Il giorno lun 21 ott 2019 alle ore 16:07 Alex Rock [e-mail]
ha scritto:

stage is interesting but I think it's not really obvious to newcomers 😕

[gsylvestre]

I like linaori's idea of SELECTED_CONFIG. Straight to the point. I wouldn't have to explain environments to students anymore!
Or maybe ACTIVE_CONFIG ?

Inspector is so good that it seems like an obvious choice.

[jeremyFreeAgent]

I use platform instead of env.

I like mode and inspection.

[drAlberT]

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.

AFAIK it is APP_DEBUG, right? so I like it very much in conjunction with APP_MODE .. I don'0t think it is confusing and it is generic enough (not bound to "symfony"), so I have deploy script to be more framework agnostic asking them all to honour the convention DEPLOY_ENV=qa, APP_MODE=prod and APP_DEBUG for example. I think these are clear, general purpose, self explanatory.

[dominikhajduk]

I like inspector or debugger.
But I'm not sure about mode. Prefer env.

[georgiana-gligor]

I agree with the mode confusing naming. I’d like to suggest setup instead, or even target.

Like this:
APP_SETUP=prod or APP_TARGET=dev

[rpkamp]

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

Ah, that explains why I'm always having trouble remembering what it's called and end up with "The Symfony ... web ... debugging ... profiling ... toolbar ... thing" :smile:

Symfony Inspector sounds a lot better :+1:

[rpkamp]

I use platform instead of env.

Other tools (like golang) use platform to indicate which OS is running. It would be really confusing to use that to replace environment in Symfony.

:+1: on APP_MODE

[Taluu]

Rather than mode, I like @ogizanagi's suggestion as runtime... mode is a bit confusing imo.

And for the profiler / inspector... Why not. Detective, Reporter maybe ?

[Tobion]

I would strongly prefer to keep "environment". We use symfony environment also as deployment environments. So "prod" is actually want is used on production, "cf_test" (for cloudfoundry) is what is used on staging, "test" is for functional tests, "dev" for local development.
So to me symfony environments can be used in any way you define them. So there is no value is renaming it as the meaning depends on the people that use it.

I'm fine for renaming the profiler though.

[dunglas]

For the record Rails, the entire Node ecosystem (popularized by Express), React, Angular and Laravel use the term "environment".

VueJS and Webpack use "mode".

Regarding the popularity of "environment", I'm not sure anymore that it is worth it to change. If we change, we should use "mode" instead of a new name used only by Symfony.

[ahundiak]

The problem with using the term Inspector in what is essentially a french product, is that people will immediately think of Inspector Clouseau and start humming the theme from the Pink Panther.

[croensch]

I'm with Rails (bkeepers/dotenv) and Node (kerimdzhanov/dotenv-flow). I prefer the 2nd Generation, with multiple files, and i'm glad Symfony adopted it.

I see no use in changing the name of this flag if it does not change in behaviour. I even think it adds more confusion. A system where environment is only used for the host and docker and infra stuff while the app has to use some arbitrary new word because it does not fit the infrastructure lingo.
I'd rather have it in sync with existing infra/backend oriented server software.
Also mind the pareto principle in that 80% of the time you run

• dev on your localhost, or a demo server
• test on your localhost, or a build server
• stage on a staging deployment
• prod on a production deployment

Thats how it should be understood and practiced. Having prod/stage parity by running prod and running prod on localhost or some server - are edge cases.

And how would we name the files then? .mode.local? Modefiles?

[linaori]

I would strongly prefer to keep "environment". We use symfony environment also as deployment environments. So "prod" is actually want is used on production, "cf_test" (for cloudfoundry) is what is used on staging, "test" is for functional tests, "dev" for local development.
So to me symfony environments can be used in any way you define them. So there is no value is renaming it as the meaning depends on the people that use it.

• dev on your localhost, or a demo server
• test on your localhost, or a build server
• stage on a staging deployment
• prod on a production deployment

This is exactly where the confusion starts. You should be able to (in theory) run every mode of symfony in every server environment. The mode is merely a "should I cache heavily?" "should I check resources and recompile on changes?" etc.

You should be able to run prod mode in local development. Why? Because you should be able to test what prod mode does when you add your feature and changes. Does it work without cache file tracking? etc.

As I specified before, my company uses a different symfony mode per environment, and this gives me nothing but headache. I have to keep track of env names for the server environment, as otherwise it will either try to compile the wrong environment, or simply not work at all.

You can still do server environment specific things if you really have to (to cover edge cases perhaps), that are not able to be solved with environment variables. For that you can introduce your own "environment" variable.

I personally think that when people use the "mode" (currently APP_ENV) for server environments, that's exactly why it should be renamed, as it's not about environments at all, it's about how Symfony works.

---

TL;DR, the above examples are exactly why it should be renamed as it shows the confusion.

[stof]

@croensch the .env file is about environment variables, not about the Symfony environment. The part of the name related to the Symfony environment in .env.prod is prod, not env.

[jvahldick]

I understand the confusion with the name env, however, I still prefer it rather than mode. It's kinda standardised among applications.

Inspector seems pretty good.

[julienbourdeau]

I agree with @dunglas.

Like I said yesteday, we're creating confusion for people from other communities.
Renaming environement will bring very little value while being a lot of work, including BC break for all projects using components like Console for instance.

You'd still have to explain to beginner, they won't instantly understand what "mode" is.

[linaori]

You'd still have to explain to beginner, they won't instantly understand what "mode" is.

@julienbourdeau I rather teach them what "mode" means, than having to explain that the symfony environment is not the server environment, because they assumed wrong.

Source: had to explain far too often on IRC/Slack.

[OskarStark]

After reading all the comments here I am more and more for: runtime

[linaori]

@OskarStark wouldn't that be confusing as it's used at compile-time? Runtime doesn't change.

[teohhanhui]

-1 for APP_MODE. The concept of an "environment" is well understood across different languages / frameworks, e.g. NODE_ENV.

EDIT: I see @dunglas already made that point above: https://github.com/symfony/symfony/issues/34042#issuecomment-544701787

[Taluu]

@OskarStark wouldn't that be confusing as it's used at compile-time? Runtime doesn't change.

Well, you're compiling the container into a runtime (prod), which wouldn't change afterwards...

[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
https://github.com/symfony/symfony/issues/34042#issuecomment-544390922

[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.