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:
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
The project name constraints articulated in compose-spec/compose-spec#314 are only enforced when using
docker compose -por thename:config file property (once #362 lands indocker compose). Non-normalized project names fromCOMPOSE_PROJECT_NAME, the project dir, or the working dir are still allowed, whichdocker composewill 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:
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 indocker compose. However, theCOMPOSE_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