The project name constraints articulated in compose-spec/compose-spec#314 are only enforced when using docker compose -p or the name: config file property (once #362 lands in docker compose). Non-normalized project names from COMPOSE_PROJECT_NAME, the project dir, or the working dir are still allowed, which docker compose will then normalize.

I'm happy to implement the necessary changes to enforce the project name constraints across all mechanisms. I'm also happy to update the documentation PR to reflect the current behavior instead, if it's desirable to leave the current behavior as is for some reason.

Background

I noticed this while preparing the following documentation change after having compose-spec/compose-spec#314 and #362 merged today:

• mbland/docs@62d5fcd

I experimented locally using all the mechanisms described in that change to confirm the current behavior.

It seems the JSON schema change from #362 will catch invalid name: values in the config (per the loader/loader_test.go failure in that PR) once it lands in docker compose. However, the COMPOSE_PROJECT_NAME, project dir, and current dir mechanisms would need an update.

Maybe users are less likely to encounter issues when the project name is defined via the other mechanisms. Still, it would seem more correct and less surprising to enforce the project name constraints across all the available mechanisms.

Related issues

• docker compose restricts project name, where the spec does not docker/compose#9741
• [SECURITY] Transversal data access unallowed can occurs silently. docker/compose#9434
• Compose v2: Inconsistent behaviour between commands when project name has leading underscores docker/compose#9429
• define compose container names with a valid hostname docker/compose#8655
• Switch to using hyphens as a separator in hostnames docker/compose#229