AssertionError when attempting to locate dotenv file

[HonakerM]

Hello,

I updated to the latest python-dotenv version (1.0.1) this morning and am now starting to see the following Assertion Errors:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
<>
  File "/usr/local/lib/python3.11/site-packages/dotenv/main.py", line 305, in find_dotenv
    assert frame.f_back is not None
           ^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

The code that generated the above looks like the following:

if path := find_dotenv(raise_error_if_not_found=False):
  load_dotenv()

Please let me know if there are any other logs or data I can provide to help the debugging/investigation process

[Bajron]

Took a look at this one.

I think we can change the assertion into breaking the loop. I checked the history and it seems the assertion is there to make static analysis happy. Traced it back to this one eb3eab8

If I understand the code correctly, this variable is None when we are the the top of the call stack. If we break the loop at that point we get reasonable guess for the path to start the lookup.

To be honest, I could not reproduce the issue with "typical" code.

I suspect introducing or not os.path.exists(frame.f_code.co_filename) caused the problem.
With this assumption I could reproduce it in the following way on Ubuntu.

Create a test.py with the following content:

#!/usr/bin/env python3
import dotenv
import os

os.unlink('test2.py')

if path := dotenv.find_dotenv(raise_error_if_not_found=False):
    print(path)
else:
    print("no path")

Create a symbolic link with ln -s test.py test2.py

Run python test2.py

Now I guess this is not your use case @HonakerM , so could you share a little more details about your scenario?
How is the script called, what is your environment, and especially, does it involve scripts moving/deleting/any other operations that can make the code think the source file does not exist?

[Bajron]

Added a PR with my suggestion. I think we still need to understand what actually happens in your environment though.
You can test it with:
pip install python-dotenv@git+https://github.com/Bajron/python-dotenv@assertion-find-dotenv-for-upstream

You might need to uninstall the old version first as the version string is still the same and pip might not apply the changes because of that.

[theskumar]

@HonakerM Would it possible for you test the fix by @Bajron and/or report more about your environment?

[HonakerM]

@theskumar sorry for the delay I will try out the fix this weekend

[jberkel]

Looks like this can happen when code is execute from a zipapp, here's a repro case:

pip install python-dotenv==1.2.1 --target foo
echo "def main():\n\timport dotenv\n\tdotenv.load_dotenv()" > foo/main.py
python -m zipapp --main=main:main -o foo.zipapp --python=python3.13 foo


$ ./foo.zipapp
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/Volumes/Case/digero/./foo.zipapp/__main__.py", line 3, in <module>
    main.main()
    ~~~~~~~~~^^
  File "/Volumes/Case/digero/./foo.zipapp/main.py", line 3, in main
    dotenv.load_dotenv()
    ~~~~~~~~~~~~~~~~~~^^
  File "/Volumes/Case/digero/./foo.zipapp/dotenv/main.py", line 374, in load_dotenv
    dotenv_path = find_dotenv()
  File "/Volumes/Case/digero/./foo.zipapp/dotenv/main.py", line 322, in find_dotenv
    assert frame.f_back is not None
           ^^^^^^^^^^^^^^^^^^^^^^^^

Looks like it also depends on the Python version, when using 3.9.6 (default on macOS), it doesn't crash, but with 3.13, it does.

It doesn't crash with the patch above by @Bajron

[Bajron]

Might be connected with another repro I found recently.
Seems reading the script from a stream breaks it.

def test_script_from_stream(tmp_path, monkeypatch):
    monkeypatch.chdir(tmp_path)
    env = tmp_path / ".env"
    env.write_text("A=xyz")
    commands = tmp_path / "commands"
    commands.write_text(
        textwrap.dedent(
            """
        from composeit.dotenv import load_dotenv
        import os
        load_dotenv() and None
        print(os.environ['A'])
    """
        )
    )
    result = subprocess.run(
        [sys.executable], check=False, stdin=open(commands), stdout=subprocess.PIPE
    ).stdout
    assert result.decode().strip() == "xyz"

The solution of breaking the loop when frame.f_back is None works fine in this case (resolves to $CWD), but for a little bit indirect reason. My notes from another fork:

        # frame_filename can be "<stdin>"" and the line below then resolves to the current working directory
        path = os.path.dirname(os.path.abspath(frame_filename))

[jberkel]

FYI, it doesn't happen when running from inside a PEX file. But OTOH, it's not able to find the .env file because it can't determine the current/script directory.