Repository navigation
dotenv_load with bad file path doesn't error #164
Description
Activity
Thank you for reporting this issue. I observe the same behavior as you. I had a look at the code and it's pretty obvious that
Trueis the only value thatload_dotenvcan return. This indeed looks like a bug.What
load_dotenvshould return is not documented as far as I know, but there are two tests that suggest it should return whether a .env file was found as a boolean.Your suggestion - raising an exception if the file wasn't found - is a good idea in general. However, it's normal for a .env file to be absent (e.g. in staging or in production), so I would say the boolean approach makes more sense here.
A boolean return value to indicate success or failure would be helpful. It looks like that's hardcoded to
Truein this function. I don't understand how the class works, so I'm not sure how that function ever interacts with the file name/path.Reacted by Sergey KuznetsovIt actually does throw an exception if you set
verbosetoTrue.verbose=Truedisplays warning if file was not found.The return value of load_dotenv is undocumented as I was planning to do something useful with it, but could not settle down to one.
I think it make sense to return proper return based on if file was found or not, but if the idea is to just stop execution if no .env is found I think it would make much more sense to just pass it a
fail_silently=Falseand have it raise an exception.It would be great to return a getter object/function as return value of
load_dotenv(). That object then can be used to get parsed values from env.e.g.
env = load_dotenv(fail_silently=False) DEBUG = env("DEBUG", cast=bool, default=False)It may also contain some of the meta info like file_path.
>> print(env.file_path) /etc/config/.envReacted by yonatanpc, Anshul Chauhan, t-h- and dfratus-trifectaI can make a PR for this! From the above discussion, my understanding is we want to have an option to fail silently or with an exception. If it fails silently, we want to reflect the status and other metadata in the return value. Do we want to do this irrespective of the value of
verboseor just whenverbose=True?My preference would be stop execution if the env file is not found, but to also be able to silently fail if desired. In general, silent failures aren't a great idea, but I think it should be an option considering the use cases for dotenv. Regardless, knowing what happened is the key whether or not verbose is set to true, which shouldn't be a requirement to know if something failed in my opinion.
I agree, my opinion is also that it should be independent of the
verbosevalue. For whether we want an exception or a silent failure to be the default, I would like to hear more opinions. I do not use it for web apps and do not have an opinion on what the default should be for that use-case.Thanks to #211, errors are not silent anymore. Does that work for you?
However, there's still no way to stop execution when syntax errors are found in the
.envfile. I think astrictoption would make sense. Such an option would be false by default at the beginning, so that it wouldn't break existing applications.Returning whether a
.envwas loaded as a boolean probably also makes sense. As mentioned earlier, I don't think we want to raise anything, not even a warning, when a.envfile isn't found, since it's normal for the file to be missing in production.Never mind my initial question about syntax warnings. It's different from the "file not found" question. I mixed up those two types of errors.
+1 for that issue.
Sad :(
Having used many other Python libraries, I personally find this behavior to be unexpected and confusing.
It would make much more sense to throw an exception if the .env file does not exist
Dotenv accepts a bad file name as
dotenv_pathand returnsTrueeven though the file could not have been loaded because it doesn't exist. I am now checking for existence of the file ahead of time, but the library really should check this on its own. Libraries that interact with files should throw exceptions when the files are inaccessible.