You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
load_dotenv() returns True even if .env file is not found #321
This behaviour is not ideal since if the configuration file is not found in the filesystem it may be better to return False.
In this way the user can write something like:
I understand the return response for load_dotenv is not ideal, but at the same time as load_dotenv just not accepts a file on the filesystem but a StringIO as well, so the return value indicating the existing of a file doesn't make any sense.
There are other ways to get around this for you use case.
Enable verbose=True in load_dotenv to get a error log if file is not found.
Use the find_dotenv function to check if the file exist or not or simply check the file yourself, before loading the values from .env.
It feel like exposing an instance of Dotenv class might make sense here or None if nothing is processed by load_dotenv. cc: @bbc2 thoughts?
so the return value indicating the existing of a file doesn't make any sense.
I think it would be OK to return True if a StringIO was provided. False would still be useful for users using files.
So I'd suggest implementing that, or changing strategies and adding a raise_if_file_not_found argument to load_dotenv and dotenv_values. One or the other, but not both.
It feel like exposing an instance of Dotenv class might make sense here or None if nothing is processed by load_dotenv.
Although it could lead to interesting features, I'm worried that exposing the Dotenv class would increase our API surface considerably. I kind of like the fact that we can change that class easily at the moment, which wouldn't be the case if we exposed it to users.
About returning None, what would be the advantage compared to returning False?
@theskumar why we can access values from .env files by just os.getenv("VARIABLE_NAME") without even calling load_env() ? Any reason?
load_env sets the environment variables of the python instance to the ones found in the file. If you don't call I, then it uses the local variables of the system.
I've submitted a PR that changes the behavior of dotenv.Dotenv.set_as_environment_variables such that load_dotenv will return False if it is unable to load any environment variables from a file or stream. I think that addresses the concerns raised in this issue.
I changed a value in my .env but kept receiving the previous value (I saved the .env file after changing it). I tried deleting the "pycache" but it did not work. When I closed the vs code terminal and opened a new one it was resolved. There is a cache but I could not understand where and why.
I changed a value in my .env but kept receiving the previous value (I saved the .env file after changing it). I tried deleting the "pycache" but it did not work. When I closed the vs code terminal and opened a new one it was resolved. There is a cache but I could not understand where and why.
@cbarkinozer load_dotenv doesn't override existing environment variables by default. Use the override argument:
load_dotenv(override=True)
There is no special cache for environment variables. They are associated with a process. In your case, I assume they were attached to the terminal in which you set them (i.e. the terminal in which you previously ran a python script in which you called load_dotenv).
This is probably not the place to ask this question, by the way, since the issue is closed and your question isn't related to it.
Activity
theskumar commentedon Jun 22, 2021
I understand the return response for
load_dotenvis not ideal, but at the same time asload_dotenvjust not accepts a file on the filesystem but a StringIO as well, so the return value indicating the existing of a file doesn't make any sense.There are other ways to get around this for you use case.
verbose=Truein load_dotenv to get a error log if file is not found.find_dotenvfunction to check if the file exist or not or simply check the file yourself, before loading the values from .env.It feel like exposing an instance of
Dotenvclass might make sense here orNoneif nothing is processed by load_dotenv. cc: @bbc2 thoughts?bbc2 commentedon Jul 3, 2021
I think it would be OK to return
Trueif aStringIOwas provided.Falsewould still be useful for users using files.So I'd suggest implementing that, or changing strategies and adding a
raise_if_file_not_foundargument toload_dotenvanddotenv_values. One or the other, but not both.Although it could lead to interesting features, I'm worried that exposing the
Dotenvclass would increase our API surface considerably. I kind of like the fact that we can change that class easily at the moment, which wouldn't be the case if we exposed it to users.About returning
None, what would be the advantage compared to returningFalse?iamsannyrai commentedon Aug 11, 2021
@theskumar why we can access values from .env files by just os.getenv("VARIABLE_NAME") without even calling load_env() ? Any reason?
ethsanders commentedon Nov 15, 2021
load_env sets the environment variables of the python instance to the ones found in the file. If you don't call I, then it uses the local variables of the system.
Return False when we do not discover any environment variables
Return False when we do not discover any environment variables
Return False when we do not discover any environment variables
larsks commentedon Mar 15, 2022
I've submitted a PR that changes the behavior of
dotenv.Dotenv.set_as_environment_variablessuch thatload_dotenvwill returnFalseif it is unable to load any environment variables from a file or stream. I think that addresses the concerns raised in this issue.Return False when we do not discover any environment variables
Return False when we do not discover any environment variables
rptaylor commentedon May 30, 2022
I think this is the same or similar to #297 ?
feat: return False when we do not discover any environment variables (#…
cbarkinozer commentedon Aug 5, 2024
I changed a value in my .env but kept receiving the previous value (I saved the .env file after changing it). I tried deleting the "pycache" but it did not work. When I closed the vs code terminal and opened a new one it was resolved. There is a cache but I could not understand where and why.
kaskogsholm commentedon Aug 16, 2024
@cbarkinozer load_dotenv doesn't override existing environment variables by default. Use the override argument:
There is no special cache for environment variables. They are associated with a process. In your case, I assume they were attached to the terminal in which you set them (i.e. the terminal in which you previously ran a python script in which you called load_dotenv).
This is probably not the place to ask this question, by the way, since the issue is closed and your question isn't related to it.
feat: add `strict` parameter to `load_dotenv()` and `dotenv_values()`
feat: add `strict` parameter to `load_dotenv()` and `dotenv_values()`
feat: add `strict` parameter to `load_dotenv()` and `dotenv_values()`
feat: add `strict` parameter to `load_dotenv()` and `dotenv_values()`