Why does it parse comments in environment variables

[mmsaki]

Why does it parse comments in environment variables

[th0rgall]

I had an issue that looked similar, but it had nothing to do with python-dotenv, instead it was caused by default behavior of VSCode that I didn't understand. I'm leaving this note for anyone else finding their way here, because I think it's highly likely this was @mmsaki's underlying issue.

It seems the built-in Python extension of VSCode has a feature that "sources" your .env file into any new VSCode terminal in a Python project (source). This is controlled by the python.envFile setting that is by default set to ${workspaceFolder}/.env. This sourcing happens in an idiosyncratic way that matches the reproduction case from the issue, see more below.

If you aren't aware of this default behavior (and of your terminal's actual environment), like I was, it can lead to unexpected results with regards to python-dotenv usage. For example, it could explain the "caching" behavior that @mmsaki observed, which was also my issue. Here's how to reproduce it:

1. Have an .env file in a Python project with some env vars.
2. Open a new VSCode terminal.
3. Change, add or remove variables in your .env file.
4. Call a Python program that uses python-dotenv's load_dotenv() in the same terminal (without override=True)
5. Observe: the initial environment variables & their values values from step (1), as sourced by VSCode, will have overridden the actual state of your .env. You're working with old state created before the program executed, hence "caching".

Additionally, I've tested the initial reproduction case from the issue, which also matches in behavior:

1. Add VARIABLE="xxxxxxx" # this is a comment to your .env
2. Have thepython.envFile workspace setting set to the default value
3. Open a new VSCode terminal
4. Run echo $VARIABLE
5. Output: "xxxxxxx" # this is a comment

This is idiosyncratic, since it is different from how zsh, bash and python-dotenv would load this env variable.

To prevent VSCode from loading .env this way, set { "python.envFile": "" } in your workspace settings.

[mmsaki]

Also the dotenv package is not watching for real time changes in the .env file. Why is this happening? This does not look good. Is the file being cached? It looks like dotenv is called on time and does not load the .env again no matter how many times you rerun your code. Wooow!

[Bajron]

I cannot reproduce your issue with the provided input.
There is however a behavior in this package that you might have encountered with slightly different input.

If your .env is (note the '#' glued to the first word):

VARIABLE=xxxxxxx# this is a comment

Then indeed the '#' does not behave as an inline comment indicator. This behavior is kind of consistent with bash.

If you source .env in bash you get bash: this: command not found
If your .env is:

VARIABLE=xxxxxxx#this_is_NOT_a_comment

and you source it in bash, you will see the VARIABLE is set to "xxxxxxx#this_is_NOT_a_comment".
So you need a space before the '#' to make it a comment in bash.

The other issue you observe might be the fact, that load_dotenv does not override existing variables by default. You can control this behavior with the named argument override. For example load_dotenv(override=True).

[theskumar]

Thanks @Bajron for help here. @mmsaki I hope this resolve your issues. Please re-open the issue if it doesn't, please be as detailed as possible.

[mmsaki]

@th0rgall yes, this was exactly the behavior I was hoping to highlight when I opened this issue. Thanks for sharing your discovery and uncovering the unexpected behaviors which are coming from the built-in Python extension in VSCode and not python-dotenv. Thank you for your effort. I am sure this will help a lot of people coming across this issue again.