Skip to content

load_dotenv() returns True even if .env file is not found #321

Closed

Description

@scollovati

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:

if load_dotenv():
    #do stuff
else
    print("No file .env found")

Steps to reproduce

In [1]: import dotenv

In [2]: dotenv.load_dotenv()
Out[2]: True

In [3]: dotenv.find_dotenv()
Out[3]: ''

Activity

  1. theskumar commented on Jun 22, 2021

    @theskumar
    Owner

    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.

    1. Enable verbose=True in load_dotenv to get a error log if file is not found.
    2. 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?

  2. bbc2 commented on Jul 3, 2021

    @bbc2
    Collaborator

    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?

  3. iamsannyrai commented on Aug 11, 2021

    @iamsannyrai

    @theskumar why we can access values from .env files by just os.getenv("VARIABLE_NAME") without even calling load_env() ? Any reason?

  4. ethsanders commented on Nov 15, 2021

    @ethsanders

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

  5. added 3 commits that reference this issue on Mar 15, 2022
    1154827
    d6fd24f
    48e3fc7
  6. larsks commented on Mar 15, 2022

    @larsks
    Contributor

    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.

  7. added 2 commits that reference this issue on Mar 15, 2022
    020ac34
    1371bb8
  8. rptaylor commented on May 30, 2022

    @rptaylor

    I think this is the same or similar to #297 ?

  9. added a commit that references this issue on Jun 5, 2022
    ee15221
  10. cbarkinozer commented on Aug 5, 2024

    @cbarkinozer

    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.

  11. kaskogsholm commented on Aug 16, 2024

    @kaskogsholm

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions