8000 [RFC] Renaming some core concepts... for the better · Issue #34042 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
fabpot opened this issue Oct 21, 2019 · 92 comments
Closed

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

fabpot opened this issue Oct 21, 2019 · 92 comments
Labels
RFC RFC = Request For Comments (proposals about features that you want to be discussed)
Milestone
5.4

Comments

@fabpot
Copy link
Member
fabpot commented Oct 21, 2019 •
edited
Loading

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
Copy link
Contributor
Pierstoval commented Oct 21, 2019 •
edited
Loading

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
Copy link
Member
dunglas commented Oct 21, 2019 •
edited
Loading

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

@dunglas
Copy link
Member
dunglas commented Oct 21, 2019

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

@javiereguiluz javiereguiluz added the RFC RFC = Request For Comments (proposals about features that you want to be discussed) label Oct 21, 2019
@javiereguiluz javiereguiluz added this to the next milestone Oct 21, 2019
@Pierstoval
Copy link
Contributor
Pierstoval commented Oct 21, 2019 •
edited
Loading

@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
Copy link
fbnlsr commented Oct 21, 2019

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member
wouterj commented Oct 21, 2019 •
edited
Loading

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
Copy link
Member Author
fabpot commented Oct 21, 2019

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
Copy link
bnd170 commented Oct 21, 2019

+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
Copy link
Mrkisha commented Oct 21, 2019 •
edited
Loading

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
Copy link
omissis commented Oct 21, 2019

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

@mazraara
Copy link

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

@drAlberT
Copy link
Contributor

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
Copy link
Member Author
fabpot commented Oct 21, 2019

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
Copy link
Contributor

@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
Copy link
Member
stof commented Oct 21, 2019

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
Copy link

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
Copy link
Contributor

I really like inspector +1

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

@Pierstoval
Copy link
Contributor
Pierstoval commented Oct 21, 2019 •
edited
Loading

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
Copy link
stunami commented Oct 21, 2019

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
Copy link
nicolasbonnici commented Oct 21, 2019 •
edited
Loading

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

@luisfaceira
Copy link

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
Copy link
Contributor
ogizanagi commented Oct 21, 2019 •
edited
Loading

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
Copy link
Mrkisha commented Oct 21, 2019

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

@julienbourdeau
Copy link

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 A3E2 other frameworks call it Environment. So we're creating confusion for people coming from other communities.

@chr-hertel
Copy link
Contributor
chr-hertel commented Oct 21, 2019 •
edited
Loading

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
Copy link

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
Copy link
Contributor

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

@ryden54
Copy link
ryden54 commented Oct 22, 2019

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

@Aerendir
Copy link
Contributor
Aerendir commented Oct 22, 2019 •
edited
Loading

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
stunami commented Oct 22, 2019

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
Copy link
Contributor

APP_CONFIG simply defines what config to load

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

@stunami
Copy link
stunami commented Oct 22, 2019

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
Copy link
Member

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

@teohhanhui
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Mrkisha commented Oct 24, 2019

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
Copy link
Contributor
dkarlovi commented Oct 24, 2019 •
edited
Loading

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

@fabpot fabpot mentioned this issue Oct 26, 2019
Closed
@juliusstoerrle
Copy link

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

@Seb33300
Copy link
Contributor

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
Copy link
Contributor

@Seb33300 it was clarified before
#34042 (comment)

@atompulse
Copy link

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
Copy link
Contributor
ro0NL commented Nov 2, 2019 •
edited
Loading

@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
Copy link
Member
stof commented Nov 28, 2019

i think switching to e.g. "application mode" co F440 uld 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)

@greg0ire greg0ire mentioned this issue Jan 6, 2020
Merged
@Tobion
Copy link
Contributor
Tobion commented Apr 10, 2020

@fabpot is this issue still relevant?

@fabpot
Copy link
Member Author
fabpot commented Apr 12, 2020

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 nicolas-grekas mentioned this issue Jul 15, 2020
Closed
@nicolas-grekas nicolas-grekas mentioned this issue Oct 7, 2020
Closed
@nicolas-grekas
Copy link
Member
nicolas-grekas commented Oct 13, 2020 •
edited
Loading

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.

@fabpot fabpot closed this as completed Oct 13, 2020
@chalasr chalasr mentioned this issue Oct 11, 2023
Merged
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
RFC RFC = Request For Comments (proposals about features that you want to be discussed)
Projects
None yet
Milestone
5.4
Development

No branches or pull requests
0