?= syntax fails since 2.0 in env_file import

[xf-]

Description

.env variables in Makefiles use ?= basally to set something, if nothing else is set (or see it as default value). In v1 of docker compose we could pass the env files to container with that syntax, no it throws an arrow about that syntax.

Steps to reproduce the issue:

1. Load an env file in your docker-compose.yaml
2. Set a variable like TEST?=fooBar
3. Run your docker-compose file using env_file and importing the env with ?=

Describe the results you received: unexpected character "?" in variable name near "TEST?=fooBar

Describe the results you expected: Running container

Output of docker compose version:

Docker Compose version 2.0.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  compose: Docker Compose (Docker Inc., 2.0.1)

Server:
 Containers: 38
  Running: 1
  Paused: 0
  Stopped: 37
 Images: 42
 Server Version: 20.10.9
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8686ededfc90076914c5238eb96c883ea093a8ba.m
 runc version: v1.0.2-0-g52b36a2d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.14.14-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.34GiB
 Name: 
 ID:
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Usage/usefulness This was really nice to have a default set of variables and a second .env file (merged by Makefile) for local overwrites or if a new variable was used, it was set for sure.

End of 6.2 Flavors section. https://www.gnu.org/software/make/manual/make.html#Flavors

More examples https://stackoverflow.com/questions/24263291/define-a-makefile-variable-using-a-env-variable-or-a-default-value

[ndeloof]

dot env file format is unfortunately a de facto convention but no official specification. docker-compose v1 was based on the python implementation, for Compose V2 we use the godotenv library which was designed to match Ruby conventions.

Those conventions all have in common .env file should align with bash usage, so one can use source .env (so the support for export prefix). Makefile custom syntax for variable is yet another aspect of this that we never considered afaik. I wonder if python-dotenv support for this is intentional or just happened "by chance" ...

[xf-]

THX for the explanation. That makes some sense, switching library (& language) and never was an expected feature.

A lot of projects use Makefiles to bundle the commands for easy usage, and we are using a combined file and looked for a way to overwrite local/project setting ?= was great for a default value.

In the worst case for me, I need a utility that does that from now on. I understand if this is out-of-scope.

[nevergone]

Related commit: https://github.com/compose-spec/godotenv/blob/655269e2565760ac457e473904300398c6150d47/parser.go#L113

[xf-]

@ndeloof there are even more issues. I saw multiple issues open and also noticed some stuff works with environments and if moved to an env file it breaks. e.g. PHP-FPM parameter with a . in variable name and godotenv has more or less no docu about the supported env features.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[xf-]

Would be still really nice in some use cases like default settings and project or local overrides them.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.