Option for Docker compatibility

[jaraco]

I was hoping to use python-dotenv to re-use the env file created for Docker. The Docker syntax, however, conflicts with the python-dotenv syntax (in how it interprets quotes).

Should python-dotenv provide a mode that's compatible with Docker's syntax?

[jamesmyatt]

Can you provide some examples?

[jaraco]

I looked for the example that spurred this request, but I'm not finding any .env values that have a quote at the beginning or end. I thought the example I encountered had a quote only at the beginning or end, but I don't see how that would have been an issue. Probably I re-generated a password to be compatible with both forms.

More importantly, looking at the code, I don't see how that if statement ever evaluates to True. The == binds first, so quoted will be assigned the value of True in ['"', "'"] or False in ['"', "'"], which is always False. Or am I mistaken?

Perhaps I encountered this issue by reading the README, which doesn't provide a detailed spec, but only examples that seem to contradict the Docker spec.

Looking into it, the intended behavior may be the same except when matching quotes are included, such as

PASSWORD="/?\"

Which will produce "/?\" on docker but probably create a crash on dotenv.

But again, I don't have an active use-case. What I'd like to see is a declaration in the README that says that dotenv supports docker .env files (full stop).

[bbc2]

With the latest dotenv, your example yields /?\ on dotenv, which is different from what you get with docker-compose: "/?\". It is also different from what you would get with Bash: a syntax error (which makes sense with regards to quoting).

My understanding is that python-dotenv attempts to mimic Bash, albeit incompletely. That's probably were those quoting rules come from, and why it differs from the format understood by docker-compose. There's even more to dotenv, like string interpolation (e.g. a=${HOME}, b=${a}).

I'm afraid it would be impossible to support docker-compose environment files without adding an option to the dotenv API. I wonder if it would be worth it.

More importantly, looking at the code, I don't see how that if statement ever evaluates to True. The == binds first, so quoted will be assigned the value of True in ['"', "'"] or False in ['"', "'"], which is always False. Or am I mistaken?

Surprisingly, this would actually work. For instance:

>>> 0 == 0 in [1]                                                                           
False
>>> 0 == 1 in [1]                                                                           
False
>>> 1 == 1 in [1]                                                                           
True
>>> 2 == 2 in [1]                                                                           
False

However, this code was indeed very hard to understand and would fail on strings of one character (e.g. '"'). This was fixed in #148.

[jaraco]

Surprisingly, this would actually work.

Wow. Okay, I've been doing Python for over 20 years and I learned something new today. I was still thinking like a C programmer, and I'd not realized that certain operations are chained left-to-right, as explained here. I knew that was true for 0 < x < 10, but I'd not realized this concept generalized to other comparisons and inclusion operators (though that makes sense now that I think about it). Thanks for the example.

I'm afraid it would be impossible to support docker-compose environment files without adding an option to the dotenv API. I wonder if it would be worth it.

It would be immensely useful in my use-case, where in development I need to switch between running natively and running the same process under docker compose. Right now, I can't do that without:

• requiring that all env values are within a subset of unescaped values in both formats, or
• keeping duplicate copies of all env settings and maintaining the values in separate formats (and thus the knowledge of the separate formats).

Honestly, I'd prefer that bash and docker-compose and dotenv could all agree on a format so that one didn't have to maintain separate env files for each platform.

Annoyingly, it seems docker compose is happy with their non-standard syntax. I do agree that docker-compose seems to be the odd-player out here.