Env files require strict whitespace

[joerobot]

Description of the issue

As of version 1.26.0 and using python-dotenv for env files, env files must have strict whitespace else error is triggered:

WARNING: Python-dotenv could not parse statement starting at line 1 WARNING: The FOO variable is not set. Defaulting to a blank string.

For example:

.env
FOO={"white":"space"} // OK (no spaces)

FOO={ "white" : "space" } // OK (single spaces)

FOO={  "white":"space"} // NOT OK (double spaces)

FOO={    "white":"space"} // NOT OK (multiple spaces)

This became an issue for me as I have several .env files that are dynamically created, obviously I could more strictly write these files as a fix but figured other people might experience this issue as they update. An update to documentation would be a sufficent fix I suppose :)

Context information (for bug reports)

Output of docker-compose version

docker-compose version 1.26.2, build eefe0d31
docker-py version: 4.2.2
CPython version: 3.7.7
OpenSSL version: OpenSSL 1.1.1g  21 Apr 2020

Output of docker version

Client: Docker Engine - Community
 Azure integration  0.1.7
 Version:           19.03.12
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        48a66213fe
 Built:             Mon Jun 22 15:41:33 2020
 OS/Arch:           darwin/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.12
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       48a66213fe
  Built:            Mon Jun 22 15:49:27 2020
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker-compose config (Make sure to add the relevant -f and other flags)

WARNING: Python-dotenv could not parse statement starting at line 1
WARNING: The FOO variable is not set. Defaulting to a blank string.
services:
  test:
    build:
      context: .
    command: 'echo '
version: '3.0'


.env
FOO={"foo":  "bar"}

Steps to reproduce the issue

1. Include a double space in a .env file
2. Echo variable in docker-compose.yaml
3. docker-compose up

Observed result

WARNING: Python-dotenv could not parse statement starting at line 1
WARNING: The FOO variable is not set. Defaulting to a blank string.
WARNING: Python-dotenv could not parse statement starting at line 1
WARNING: Python-dotenv could not parse statement starting at line 1
Recreating test ... done
Attaching to composetest_test_1
test_1  | 
composetest_test_1 exited with code 0

Expected result

Foo variable is echoed.

[Pomax]

As a team member on a project that never installed python-dotenv, running into this has been quite the frustration: rather than a mere docs update, there is no reason to force a stricter .env format: can this rule be turned off again? We don't even have complex rules, it's tripping up over things that are absolutely supposed to work, like CSP_FONT_SRC='self' https://fonts.gstatic.com https://fonts.googleapis.com, and it doesn't even seem to offer anything helpful beyond saying "something" is wrong, not "what" is wrong:

WARNING: Python-dotenv could not parse statement starting at line 47
WARNING: Python-dotenv could not parse statement starting at line 51
WARNING: Python-dotenv could not parse statement starting at line 53
WARNING: Python-dotenv could not parse statement starting at line 55
WARNING: Python-dotenv could not parse statement starting at line 56
WARNING: Python-dotenv could not parse statement starting at line 57
WARNING: Python-dotenv could not parse statement starting at line 47
WARNING: Python-dotenv could not parse statement starting at line 51
WARNING: Python-dotenv could not parse statement starting at line 53
WARNING: Python-dotenv could not parse statement starting at line 55
WARNING: Python-dotenv could not parse statement starting at line 56
WARNING: Python-dotenv could not parse statement starting at line 57
WARNING: Python-dotenv could not parse statement starting at line 47
WARNING: Python-dotenv could not parse statement starting at line 51
WARNING: Python-dotenv could not parse statement starting at line 53
WARNING: Python-dotenv could not parse statement starting at line 55
WARNING: Python-dotenv could not parse statement starting at line 56
WARNING: Python-dotenv could not parse statement starting at line 57
WARNING: Python-dotenv could not parse statement starting at line 47
WARNING: Python-dotenv could not parse statement starting at line 51
WARNING: Python-dotenv could not parse statement starting at line 53
WARNING: Python-dotenv could not parse statement starting at line 55
WARNING: Python-dotenv could not parse statement starting at line 56
WARNING: Python-dotenv could not parse statement starting at line 57
WARNING: Python-dotenv could not parse statement starting at line 47
WARNING: Python-dotenv could not parse statement starting at line 51
WARNING: Python-dotenv could not parse statement starting at line 53
WARNING: Python-dotenv could not parse statement starting at line 55
WARNING: Python-dotenv could not parse statement starting at line 56
WARNING: Python-dotenv could not parse statement starting at line 57

[tgsmith61591]

Anyone make any progress on this?

[lil12t]

Anyone make any progress on this?

I've got the same problem, the issue was in CI/CD config, it was SERVICE_NAME:'value' instead of SERVICE_NAME=value.

[franzwong]

I got the same problem when my env looks like this.

TEST="Hello","World"

[cobolbaby]

Need to add double quotes to the value.

e.g. TEST="'Hello','World'"

[Pomax]

yes, that's one of the things you need to do in "strict" mode, but there is no reason for Docker to force strict env parsing in the first place, and at the very least that should be an option that can be turned on/off.

[cobolbaby]

From the docker-compose release notes, I found that python-dotenv was introduced into version 1.26 . I suspect that the root cause of the problem is due to the compatibility ofpython-dotenv.

[JIBSIL]

Just try enclosing it in doublequotes (")

[Rillke]

The format is not formally specified and still improves over time. That being said, .env files should mostly look like Bash files.

theskumar/python-dotenv says.

docker-compose .env files were supposed to be simple key=value pairs without any quoting or escaping. Having an evolving non-standardized-format as a base seems to be risky to me, especially since it only raises a warning and deployment might continue without your database password being set ;-)

The following syntax rules apply to the .env file:

Compose expects each line in an env file to be in VAR=VAL format. Lines beginning with # are processed as comments and ignored. Blank lines are ignored. There is no special handling of quotation marks. This means that they are part of the VAL.

(emphasized by me) The docs needs to be updated if the change from v.1.26 is supposed to stay. But naturally, I would be cautious changing data format parsing without any big announcement.

[vasiliy-bout]

I've stumbled across the same issue: docker-compose behaviour violates the documentation.

Docs say:

• There is no special handling of quotation marks. This means that they are part of the VAL.

However the current behaviour is different. There is an open issue for documentation: https://github.com/docker/docker.github.io/issues/12000

It is also worth keeping in mind that if you provide the same environment file to docker run command using --env-file argument, then docker run handles the file exactly as it is stated in the documentation. So behaviour is different between docker and docker-compose.

[Pomax]

Having been bitten by this so many times now in CSP strings, which will immediately stop everything from working: val="thing" breaks one side. val=thing breaks the other side. But val=" thing ", for whatever insane reason, seems to work.

[vlasvlasvlas]

is this still an issue right?

[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.

[Pomax]

Dear whoever-run-this-repo: please configure your bot properly. An issue that never got triaged and never even got looked at by someone on the team should NEVER be automatically marked stale. It should be forced into the triage queue. Stale means the dev team saw it, responded to it, asked for information, and no one bothered to ever follow up on that request. This issue is not stale: this issue is -despite when it was filed- still a new issue that needs triaging.

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.

[rossco555]

Same issue for me...

[nicksieger]

I'm sorry this issue has been ignored for this long, to the point where it won't be fixed in compose v1 due to the end-of-life policy. Are you able to try with compose v2 and do you still have the issue there?

[rossco555]

I tried to upgrade to 2.10.1 on my Synology NAS but I was unsuccessful. I'm not sure if there is a latest supported version for DSM7 and so gave up there.

On Thu, 25 Aug 2022, 12:04 am Nick Sieger, @.***> wrote:

I'm sorry this issue has been ignored for this long, to the point where it won't be fixed in compose v1 due to the end-of-life policy https://github.com/docker/roadmap/issues/257. Are you able to try with compose v2 and do you still have the issue there?

— Reply to this email directly, view it on GitHub https://github.com/docker/compose/issues/7624#issuecomment-1225928426, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFMQFWO7VFSKEN5FFCWWZ7LV2ZB2BANCNFSM4PFV57NQ . You are receiving this because you commented.Message ID: @.***>

[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.

[stale[bot]]

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