Adding profiles: as a top level entry to the root compose

[G3nomaly]

Description

So normally u can use the docker compose up command with the --profile tag to run any profile from the root compose. This works great, but I generally do not like flags in production code as it requires people to write / use it consistently, which is just hard to enforce. Something that would solve this in my opinion. is adding the profiles field to the root compose. allowing us to run the profiles through a button similar to how the current services work in vscode. imo this just prevents drift between team members way better.

At the same time, I am just a random dev. So do with these ideas however u like. Most likely, u have plenty of PRs and suggestions overwhelming u every day due to the rise in ai.

Just know, I love this software :D thank u very much

# Root compose.yaml
version: "4.0"

# 1. Native includes pulling in the raw module files
include:
  - path: ./modules/auth/compose.yaml
  - path: ./modules/billing/compose.yaml
  - path: ./modules/accounting/compose.yaml

# 2. Global Control Plane: Tweaking behavior for profile-tagged services
profiles:
  billing:
    unify_prefix: true
    group: false
    group_network: true
    env_file: .env.billing

  accounting:
    unify_prefix: false
    group: false
    group_network: true
    env_file: .env.accounting

  complete-stack:
    unify_prefix: false
    group: true
    group_network: true
    env_file: .env.global

[ndeloof]

👎
If we hard-code profiles in yaml then profiles makes no sense anymore (there's no way to disable a profile)
if you don't like flags, you can use COMPOSE_PROFILES env var (or set it in .env file)

As an alternative, I had in mind to make profile activation automated based on some observable, inspired by Apache Maven profiles: a Profile would then be automatically enabled if some env var is set, OS is XXX, File Foo is present, etc.