Does not load from current directory

[RazerM]

The README states (emphasis mine)

The easiest and most common usage consists on calling load_dotenv when the application starts, which will load environment variables from a file named .env in the current directory

I'm not finding this to be the case. load_dotenv defaults to calling find_dotenv():

python-dotenv/dotenv/main.py

Lines 249 to 251 in b20d818

	def load_dotenv(dotenv_path=None, stream=None, verbose=False, override=False):
	f = dotenv_path or stream or find_dotenv()
	return DotEnv(f, verbose=verbose).set_as_environment_variables(override=override)

but usecwd defaults to False:

python-dotenv/dotenv/main.py

Lines 224 to 246 in b20d818

	def find_dotenv(filename='.env', raise_error_if_not_found=False, usecwd=False):
	"""
	Search in increasingly higher folders for the given file
	Returns path to the file if found, or an empty string otherwise
	"""
	if usecwd or '__file__' not in globals():
	# should work without __file__, e.g. in REPL or IPython notebook
	path = os.getcwd()
	else:
	# will work for .py files
	frame_filename = sys._getframe().f_back.f_code.co_filename
	path = os.path.dirname(os.path.abspath(frame_filename))
	for dirname in _walk_to_root(path):
	check_path = os.path.join(dirname, filename)
	if os.path.exists(check_path):
	return check_path
	if raise_error_if_not_found:
	raise IOError('File not found')
	return ''

In my case, path becomes '<venv path>/lib/python3.6/site-packages/dotenv' on line 236 so the current directory is never traversed.

[cjauvin]

I confirm, I'm trying this package for the first time this morning (I learned about its existence through Flask 1.0's announcement yesterday), and the only way to make it work in my context (without specifying an explicitdotenv_path I guess) is to manually set usecwd to True, there:

https://github.com/theskumar/python-dotenv/blob/master/dotenv/main.py#L250

[jimdickinson]

I think there was an assumption that the virtual environment would be rooted in the current working directory, which is often not the case. My problem is that pipenv puts the virtual environment in my home directory under a .local directory, so frame_filename is something like $HOME/.local/share/virtualenvs/<projectname>-<hash>/lib/python2.7/site-packages/dotenv/main.py when find_dotenv is called from load_dotenv. Calling find_dotenv() with no arguments in my code works, because then frame_filename is my calling code under the current working directory.

[ClintOxx]

Yea I am running into the same exact problems they are having

[cjauvin]

This should have been fixed by 5238808, which was recently merged.

[theskumar]

@cjauvin @ClintOxx i'll make a new release sometime today. Hope this helps. Else you can install the latest master and see if that fixes your issue.

[ClintOxx]

@theskumar alright will do, thanks!

[djbriane]

I'm running into the same issue on my Ubuntu server with Python 2.7 (had no problems in my local environment from the master branch) and had to use the following:

BASE_DIR = os.path.abspath(os.path.dirname(__file__))
load_dotenv(dotenv_path=os.path.join(BASE_DIR, ".env"))

I'm not familiar enough with Python to make a pull request but thought I'd share my workaround in case it helps anyone else.

[ClintOxx]

Yea that was what I ended up doing as well @djbriane

[sloria]

I've confirmed that loading from the current directory is working in 0.9.1.

# ./.env
FOO=bar

# ./t.py
import os
from dotenv import load_dotenv

load_dotenv()

print(os.environ['FOO'])  # prints 'bar'

@theskumar I believe this issue can be closed.

[theskumar]

Great thanks @sloria ! 👍

[codewithlennylen]

The code below worked out for me after all the numerous solutions above failed to work out for me.
The .env file is in the same directory as the file below

test.py

import os
from dotenv import load_dotenv

basedir = os.path.abspath(os.path.dirname(__file__))
load_dotenv(os.path.join(basedir, '.env'))

[sanmai-NL]

@sloria @theskumar This only works when the Python source file is in the current working directory. It doesn't work for packages installed in site packages.

[QwertyJack]

I believe this is unexpected. When a third-party package mentions support for .env, users expect to configure variables using a .env file in the current directory rather than the site package directory.

[theskumar]

I believe this is unexpected. When a third-party package mentions support for .env, users expect to configure variables using a .env file in the current directory rather than the site package directory.

I believe this can be taken up by the third-party package.

Also, this package doesn't document or provide any prescription on how to use it inside another installable package. This package is primarily designed to be used independent.