fix: return clear error when COMPOSE_FILE points to a directory

[m-alikhizar]

What does this PR fix?

Fixes #13649

When COMPOSE_FILE is set to an empty string (or any value that resolves to a directory via filepath.Abs), running docker compose up -d produces the cryptic OS-level error:

read <path>: is a directory

This happens because compose-go's ReadConfigFiles calls os.ReadFile on the resolved path, which returns EISDIR when the path is a directory. The error surfaced as a raw syscall message with no guidance for the user.

What changed?

Added an explicit pre-check in two places that are responsible for loading project config:

• pkg/compose/loader.go – in LoadProject, before delegating to compose-go
• cmd/compose/compose.go – in ToModel, used by commands like docker compose config

The check iterates the resolved ConfigPaths and, for any path that is not stdin (-) or a remote resource (git/OCI), verifies it is not a directory. If it is, a clear actionable error is returned:

path "<path>" is a directory, not a Compose file; check the COMPOSE_FILE environment variable or the -f flag

Testing

• Added unit test TestLoadProject_DirectoryAsComposeFile in pkg/compose/loader_test.go that:
  • passes a temp directory as a config path
  • asserts the new human-readable error is returned
  • asserts the old read <path>: is a directory message is not present
• All existing TestLoadProject_* tests continue to pass
• Linted with golangci-lint v2.11.3 (project-pinned version) – 0 issues

Before / After

Scenario	Before	After
COMPOSE_FILE="" in empty dir	read /path/to/dir: is a directory	path "/path/to/dir" is a directory, not a Compose file; check the COMPOSE_FILE environment variable or the -f flag
docker compose -f /some/dir up	same cryptic error	same clear error
Normal empty dir (no config)	no configuration file provided: not found	unchanged

[glours]

Thanks for contributing this fix!

However, I'm not sure this PR addresses the root cause described in the issue. According to the bug report, the misleading error read : is a directory occurs when the user has no permission to access the Docker socket. In that case, the connection to the Docker daemon fails, which seems to cause ConfigPaths to resolve to the current working directory as a fallback — and that's what triggers the confusing message.

The fix improves the error message for the directory case, but it points the user toward checking COMPOSE_FILE or the -f flag, which is not the actual problem here. Someone hitting this scenario would still be confused.

Could you investigate where the socket permission error is swallowed and make sure it surfaces directly instead? That would properly address the issue as reported.