Remove default environment

[sdelamo]

Issue description

Remove Default environment.

The Micronaut framework supports the concept of one or many default environments. A default environment is one that is only applied if no other environments are explicitly specified or deduced.

In my projects, I often use the following configuration:

public class Application {

    @ContextConfigurer
    public static class DefaultEnvironmentConfigurer implements ApplicationContextConfigurer {
        @Override
        public void configure(@NonNull ApplicationContextBuilder builder) {
            builder.defaultEnvironments(Environment.DEV);
        }
    }

    public static void main(String[] args) {
        Micronaut.run(Application.class, args);
    }

Then, I will have a class such as:

@Requires(env = Environment.DEVELOPMENT)
@Singleton
public class Bootstrap implements ApplicationEventListener<ServerStartupEvent> {

    @Override
    public void onApplicationEvent(ServerStartupEvent event) {
    // Add seed data for local development. 

In Micronaut Framework 4, we disabled cloud environment education by default.

Today, if you take a Micronaut Application 4 and deploy it to a cloud environment (e.g., Elastic Beanstalk). The application starts with the default environment (the dev environment) because no other environment is detected. As you can see, this could cause harm to the user application as code he expects only to run while development locally could run in their production environment.

Suppose the user does not want the default, the dev environment, to be loaded. In that case, he needs to specify the environment variable MICRONAUT_ENVIRONMENTS=ec2 or MICRONAUT_ENVIRONMENTS=prod in their ElasticBeanstalk configuration. By doing that, the default environment, the dev environment, will not be loaded.

I suggest that for Micronaut Framework 5, we remove the concept of default environment. Instead, we modify our build plugins to automatically add the dev environment when you run ./gradlew run or ./mvnw mn:run.

I am unsure what other use cases the default environment is currently used for other than a dev env.

[driverpt]

I'd say let the person developing in charge of defining what are the Environments that they want active. IMHO, no Default is a good option

[alvarosanchez]

By default, there is no default environment. To have one, you purposely have to opt in, with an ugly context configurer idiom, btw.

So purposely defining a default environment and then not configuring one for production is shooting yourself in your foot.

What if a developer configures development or testing values in their application.yml and then they don't configure any production environment nor production configuration? Honestly, deploying to production is a strong responsibility, and it's the user's accountability to know what code and configuration they deploy.

The problem I see with the alternative you propose is that you miss the use case of running from the IDE.

[sdelamo]

@alvarosanchez If I understand you correctly, you suggest to keep it as is.

[alvarosanchez]

@alvarosanchez If I understand you correctly, you suggest to keep it as is.

Either that, or find a way to activate this dev environment when running from the IDE. Perhaps we can ask JetBrains?

[graemerocher]

I don't see any reason to change anything. The feature is opt-in

[saw303]

I would keep this as is and do not change anything.

[katoquro]

As a user, I prefer to set env explicitly via args and always use deduceEnvironment(false)

The only case I see is friendly IDE integrations to run your apps w/o additional configuration. However, you can run configured Gradle task run via IDE 😁

[altro3]

Bad idea to delete default env.

My opinion: this developer does not correctly use the concept of a default environment. A default environment is what is required always and everywhere. For example, in my case, I load country zip codes through the environment, something like this:

     public void configure(ApplicationContextBuilder builder) {
         builder.deduceEnvironment(false)
                 .banner(false)
                 .defaultEnvironments("zip-codes");
     }

But using the settings of one of the application deployment environments as default settings is not at all correct.

Each development environment requires its own profile (environment), and certainly none of them should be turned on automatically, but must be set explicitly through an environment variable, for example, in helm charts, at the global level, or at the level of one chart.

Actually, deleting a feature simply because someone didn’t understand how to use it is sacrilege